Что мы действительно используем? Возможно, другие люди на самом деле создают формальные схемы, но по большей части я просто набрасываю пузыри, поля и строки на листе бумаги.
Итак, вопрос в том,
есть ли какие-нибудь методы для ускорения таких запросов?
Ну, не совсем. Механизм хранения на основе столбцов, вероятно, будет быстрее с этими запросами SELECT COUNT (*), но он будет менее производительным для практически любого другого запроса.
Лучше всего поддерживать сводную таблицу с помощью триггеров. У него не так много накладных расходов, и часть SELECT будет выполняться мгновенно, независимо от размера таблицы. Вот шаблонный код:
DELIMITER //
CREATE TRIGGER ai_books AFTER INSERT ON books
FOR EACH ROW UPDATE books_cnt SET total = total + 1 WHERE status = NEW.status
//
CREATE TRIGGER ad_books AFTER DELETE ON books
FOR EACH ROW UPDATE books_cnt SET total = total - 1 WHERE status = OLD.status;
//
CREATE TRIGGER au_books AFTER UPDATE ON books
FOR EACH ROW
BEGIN
IF (OLD.status <> NEW.status)
THEN
UPDATE books_cnt SET total = total + IF(status = NEW.status, 1, -1) WHERE status IN (OLD.status, NEW.status);
END IF;
END
//
от: http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html
InnoDB не ведет внутренний подсчет строк в таблице. (На практике это было бы несколько сложно из-за поддержка нескольких версий.) Чтобы обработать SELECT COUNT (*) FROM t, InnoDB должен сканировать индекс таблицы, который занимает некоторое время, если индекс не полностью в буферном пуле.
Предлагаемое решение:
Чтобы получить быстрый подсчет, вы должны использовать столик вы создаете сами и пусть ваше приложение обновит его согласно вставкам и удаляет оно делает. ПОКАЗАТЬ СТАТУС ТАБЛИЦЫ также может быть используется, если приблизительное количество строк
Вкратце: count (*) (на innoDB) займет много времени для таблиц, содержащих большое количество строк. Это сделано намеренно, и ничего не поделаешь.
Напишите свой собственный обходной путь.
MyISAM на самом деле довольно быстро работает с count (*), недостатком является то, что хранилище MyISAM не так надежно, и его лучше избегать там, где целостность данных критична.
InnoDB может очень медленно выполнять запросы типа count (*), потому что он разработан для обеспечения возможности одновременного просмотра одних и тех же данных несколькими способами. Таким образом, в любой момент времени недостаточно перейти к индексу, чтобы получить счет.
От: http://www.mail-archive.com/ mysql@lists.mysql.com /msg120320.html
База данных начинается с 1000 записей в нем я начинаю транзакцию вы начинаете транзакция удаляю 50 записей Вы добавить 50 записей. Я делаю COUNT () и вижу 950 записей. Вы делаете COUNT () и видите 1050 записей. Я совершаю свою транзакцию - база данных теперь имеет 950 записей для всех, кроме вас. Вы совершаете свой транзакция - в базе 1000 записи снова.
Как InnoDB отслеживает, какие записи "видимы" или "изменяемы" с уважение к любой транзакции осуществляется через блокировка на уровне строк, транзакция уровни изоляции и многовариантность. http://dev.mysql.com/doc/refman/4.1/en/innodb-transaction-model.html http://dev.mysql.com/doc/refman/4.1/en/innodb -multi-versioning.html
Вот что заставляет подсчитывать, сколько записи, которые может видеть каждый человек, не так
Итак, суть в том, что вам нужно будет как-то взглянуть на кеширование счетчиков, а не на обращение к таблице, если вам нужно часто и быстро получать эту информацию.