как sql считает работу?
Я хотел бы понять, как точно делает работу количества sql. Действительно ли это - целое сканирование таблицы, которое происходит или является этим некоторое свойство таблицы, которая читается. Однако я чувствую, что сканирование таблицы было бы издержками в случае огромных таблиц с большим количеством записей.
8 ответов
В общем случае выполняется либо сканирование таблицы, либо сканирование индекса. Это связано в первую очередь с тем, что в движке, поддерживающем MVCC, разные транзакции могут видеть разные строки, поэтому не существует единого "подсчета строк", который был бы одновременно корректен для всех.
Аналогично, если у вас есть предложение WHERE, то условие where может быть разным для разных клиентов, поэтому они видят разные числа.
Если вам нужно выполнить много подсчетов в больших таблицах, подумайте о хранении собственных счетчиков в другой таблице. Как именно это делать, зависит от конкретного приложения.
Это будет сильно зависеть от того, какую реализацию SQL вы используете (MS SQL Server, MySQL, Oracle, PostgreSQL и т.д.), и насколько умным является его оптимизатор.
Это также может зависеть от запроса. Например, при запросе типа
SELECT COUNT(primary_key) FROM table;
оптимизатор может понять, что нет необходимости сканировать таблицу (поскольку нет фильтрации с помощью WHERE и нет возможности, что какие-то значения являются NULL) и просто вернуть размер таблицы. При более сложном запросе (где есть фильтрация или возможность NULL), базе данных может потребоваться сканирование таблицы, или она может сделать некоторую оптимизацию с использованием индекса.
Это, очевидно, зависит от реализации (т. Е. Разные СУБД могут использовать разные стратегии) и от использования (т. Е. выберите счетчик (*) из mytable и выберите счетчик (*) из mytable, где myfield
Если вы пытаетесь получить счет на основе некоторого разбиения, которое уже выражено индексом, интеллектуальные БД попытаются использовать только индекс. Или что-то вроде старого «рашмора», используемого в Foxbase.
Итак, «это зависит», но в конце концов, если нет лучших методов, да, БД выполнит сканирование таблицы.
Обычно это что-то вроде сканирования индекса, если в таблице нет уникального индекса.
Как ни странно, большинство движков баз данных могут считать только путем сканирования. Они даже предоставляют альтернативные решения для подсчета с использованием метаданных таблицы. Например, SQL Server поддерживает SELECT rowcnt FROM sysindexes ... . Однако они обычно не являются на 100% точными.
YSE COUNT FUNCTION DOSE TABLE SCAN, вместо использования счетчика в таблице для получения общего количества строк вы можете использовать:
SELECT
Total_Rows= SUM(st.row_count)
FROM
sys.dm_db_partition_stats st
WHERE
object_name(object_id) = 'TABLENAME'
или
SELECT sysobjects.[name], max(sysindexes.[rows]) AS TableRows
FROM sysindexes INNER JOIN sysobjects ON sysindexes.[id] = sysobjects.[id]
WHERE sysobjects.xtype = 'U' and sysobjects.[name]='tablename'
GROUP BY sysobjects.[name]
ORDER BY max(rows) DESC
ДРУГОЙ СПОСОБ ПОЛУЧЕНИЯ ОБЩЕГО СЧЕТЧИКА: http: //www.codeproject .com / Tips / 58796 / Number-of-different-way-to-get-total-no-row-fro.aspx
Это зависит от используемой СУБД.
Если есть индекс, должна быть одна строка индекса для каждой строки таблицы. Умная СУБД, скорее всего, выберет наименьший индекс и посчитает строки индекса.
Наконец, если таблица достаточно мала, она может подсчитать строки таблицы и обойти индекс.
В PostgreSQL выполняется сканирование таблицы. Я думаю, это зависит от реализации.
Редактировать: см. эту ссылку
Это действительно не имеет значения!
Я предполагаю, что вам нужен счетчик строк для какого-то вида подкачки... так что просто убедитесь, что ваш алгоритм подкачки соответствует лучшим практикам, и забудьте о том, как работает движок.
Пусть об этом заботятся люди, занимающиеся базами данных, просто следуйте рекомендациям тех, кто является экспертом в используемой вами базе данных.
SQL Server - http://www.4guysfromrolla.com/webtech/042606-1.shtml
Oracle - Paging with Oracle
MySQL - http://php.about.com/od/phpwithmysql/ss/php_pagination.htm