структура таблиц mysql - одна очень большая таблица или отдельные таблицы?
Мы можем попробовать подход календарной таблицы здесь, где таблица календаря содержит диапазоны, которым вы хотите соответствовать:
WITH cte AS (
SELECT 1 AS start, 499999 AS end UNION ALL
SELECT 700001, NULL
)
SELECT
t2.ItemId,
t1.start,
COALESCE(t1.[end], t2.[To]) AS [end]
FROM cte t1
INNER JOIN ItemRange t2
ON (t2.[From] <= t1.[end] OR t1.[end] IS NULL) AND t2.[To] >= t1.start
WHERE
t2.ItemId = 1;
[117 ] Демонстрация
5 ответов
Если данные универсальны, пойдите с одной таблицей. Если когда-нибудь необходимо ВЫБИРАТЬ через все веб-сайты, имеющие несколько таблиц, боль. Однако, если Вы пишете достаточно сценариев, можно сделать это с несколькими таблицами.
Вы могли использовать механизм устройства хранения данных СЛИЯНИЯ MySQL, чтобы сделать, ВЫБИРАЕТ через таблицы (но не ожидайте хорошую производительность и не упускайте жесткий предел Windows количества открытых файлов - в Linux, Вы можете haveto использовать ulimit для повышения предела. Нет никакого способа сделать это в Windows).
Я повредил огромную таблицу во много (сотни) таблиц и использовал СЛИЯНИЕ для ВЫБОРА. Я сделал это так, я мог выполнить офлайновое создание и оптимизацию каждой из маленьких таблиц. (Например, ОПТИМИЗИРУЙТЕ или ALTER TABLE... ORDER BY). Однако производительность ВЫБОРА с помощью СЛИЯНИЯ заставила меня писать свой собственный механизм устройства хранения данных. (Описанный http://blog.coldlogic.com/categories/coldstore/'> здесь)
Я сказал бы, используют дизайн, что большинство имеет смысл, учитывая Ваши данные - в этом случае одна большая таблица.
Записи все будут тем же типом с теми же столбцами, таким образом, с точки зрения нормализации базы данных они будут иметь смысл иметь их в той же таблице. Индекс делает выбирающие конкретные строки легкими, особенно когда целые запросы могут быть удовлетворены данными в единственном индексе (который может часто иметь место).
Обратите внимание, что анализ посетителя обязательно включит много операций, где нет никакого простого способа оптимизировать кроме воздействовать на большое количество строк сразу - например: количества, суммы и средние числа. Это типично для интенсивно использующей ресурсы статистики как это, чтобы быть предварительно вычисленным и сохраненным, вместо того, чтобы выбранным живое. Это - что-то, о чем Вы хотели бы думать.
Используйте единственную структуру данных. После того как Вы начинаете встречаться с проблемами производительности существует много решений как Вы, может разделить Ваши таблицы идентификатором веб-сайта, также известным как горизонтальное разделение, или можно также использовать репликацию. Это все зависит от отношение чтений по сравнению с записями.
Но поскольку запуск сохраняют вещи простыми и используют одну таблицу с надлежащей индексацией. Можно также определить, нужны ли Вам транзакции или нет. Можно также использовать в своих интересах всевозможные mysql механизмы устройства хранения данных как MyIsam или NDB (в кластеризации памяти) для повышения производительности. Также кэширование играет очень хорошую роль в разгрузке загрузки из базы данных. Данные, которые главным образом только для чтения и могут быть вычислены легко, обычно помещаются в кэш, и кэш служит запросу вместо того, чтобы идти в базу данных, и только необходимые запросы переходят к базе данных.
Используйте одну таблицу, если у Вас нет проблем производительности с MySQL.
Никто здесь не может ответить на вопросы производительности, необходимо просто сделать тесты производительности сами для понимания, достаточно ли наличие одной большой таблицы.