Форум MySQL

переставайте пороть чушь.
Такие решения провоцируют базу на логические противоречия.
А для ускорения нужно применять аккуратные запросы, оптимально построенные индексы, как указал Unkind.
Если и этого не хватает, можно разбить таблицу на частый-легкий и редкий-тяжелый контент, как по вертикали (вынеся тела сообщений в параллельную таблицу) так и по горизонтали (разделив таблицу на свежак и архив) . Это денормализация, конечно... но во благо.

Разваливаться НИЧЕГО не начнет
А как же подсчет сообщений в теме для постраничной навигации?

Не понятно о чем спор. Добавьте индексы и сравните скорости.

Разваливаться НИЧЕГО не начнет... т.к. эти поля по большей части просто информационные и не завязаны ни на что...

А их верификация - еще раз говорю... на любую операцию изменения темы повесить запрос update srvtbl set thcnt=(select count(*) from themes); (синтаксис ошибочен 100% - тут суть указана)... и так же для постов - это более чем легко....

Надо просто ставить индексы на столбцы, по которые учавствуют в условиях (WHERE). Тогда "гораздо" не будет...
А вот "ручной" подсчет создает массу проблем. Если что случилось, что начнет все разваливаться.

> Подсчитывать лучше заново каждый раз.
серьезно?

Я бы возразил, причем полностью обоснованно... Это касается и кол-ва тем и кол-ва постов в темах.

Для мааааленьких форумов - это не играет никакой роли... а теперь берем этот же форум через полгода... Когда кол-во постов суммарно будет нескольно сотен тысяч и тем неколько тысяч...

Для получения кол-ва тем запрос "select count(*) from thems" - терпимо, может быть... а вот для кол-ва постов уже другое (хотя и схоже) "select count(*) from posts where thems_id=456"

Такие запросы на больших таблицах займут мало того, что время, но и добавят нагрузки на сервак, что повлечет замедление выполнения запросов - итог - форум подтормаживать начинает...

Если на то пошло - правильнее будет иметь маленькую служебную табличку, куда вносить кол-во тем (+1 при создании/разбивании, -1 при удалении/слиянии... ил тупо на все операции повесить пересчет оператором count(*))...
А в таблице тем добавить поле - кол-во сообщений (опять-же изменять только при создании/удалении/слиянии/разбитии/переносе постов... отслеживать или простым пересчетом)...

Для чтения форум ГОРАЗДО быстрее будет работать, а для внесения изменения в одну табличку - замедление операций будет не так заметно + привычнее для людей, т.к. любой посетитель больше времени занимается ЧТЕНИЕМ форума, а не писаниной...

id должен быть либо PRIMARY KEY, либо UNIQUE KEY, либо просто INDEX.

а почему ошибка? что не так?

Можете int. Максимальный id тогда не может быть больше 2147483647. Можете unsigned int. В два раза больше - 4294967295.

id должен быть либо PRIMARY KEY, либо UNIQUE KEY, либо просто INDEX.

а тип для поля id какой? INT?

Вот мой запрос:

CREATE TABLE `forum` (

`id` INT( 1 ) NOT NULL AUTO_INCREMENT ,
`name` TEXT NOT NULL ,
`see` TEXT NOT NULL ,
`post` TEXT NOT NULL ,
`end` TEXT NOT NULL
)

Ответ MySQL:

#1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key

UPDATE `for_you` SET `ball` = `ball` + 5 WHERE `dot` = 123;