Необходимые знания для проектирования баз данных. Это краеугольный камень будущего развития.

оглавление

Необходимые знания для проектирования баз данных. Это краеугольный камень будущего развития.

1. Спецификация команд базы данных

Во-вторых, основные проектные характеристики базы данных

Три, спецификации дизайна поля базы данных

Четыре, индекс дизайна спецификации

Пять общих рекомендаций по столбцу индекса

Шесть, как выбрать порядок столбцов индекса

Семь, избегайте создания избыточных индексов и повторяющихся индексов

Восемь, отдайте приоритет индексам покрытия

Девять, индекс SET спецификации

10. Спецификации разработки базы данных SQL

11. Кодекс поведения при работе с базой данных

1. Спецификация команды базы данных
· Все имена объектов базы данных должны использовать строчные буквы и разделяться символами подчеркивания.

· Все имена объектов базы данных запрещают использование зарезервированных ключевых слов MySQL (если имя таблицы содержит ключевые слова для запроса, вам необходимо заключить его в одинарные кавычки)

· Именование объектов базы данных должно распознаваться по их именам, а окончательное число не должно превышать 32 символа.

· Временные таблицы базы данных должны иметь префикс tmp_ и суффикс даты, а таблицы резервных копий должны иметь префикс bak_ и суффикс даты (метка времени)

· Все имена столбцов и типы столбцов, в которых хранятся одни и те же данные, должны быть согласованными (обычно как связанные столбцы, если связанные типы столбцов несовместимы во время запроса, неявное преобразование типов данных будет выполнено автоматически, что приведет к тому, что индекс столбца станет недействительным и снизит эффективность запроса)

2. Базовые спецификации проекта базы данных
1. Все таблицы должны использовать механизм хранения Innodb.
Нет никаких особых требований (то есть функций, которым Innodb не может соответствовать, таких как хранение столбцов, данные пространства хранения и т. Д.), Все таблицы должны использовать механизм хранения Innodb (mysql5.5 Myisam использовался по умолчанию раньше, а Innodb - по умолчанию после 5.6) Innodb поддерживает транзакции, поддерживает блокировки на уровне строк, лучшую возможность восстановления и лучшую производительность при высоком параллелизме
2. Наборы символов базы данных и таблиц используют UTF8 единообразно, что обеспечивает лучшую совместимость. Унифицированный набор символов позволяет избежать искажения символов, вызванного преобразованием набора символов. Преобразование различных наборов символов перед сравнением приведет к сбою индекса.
3. Ко всем таблицам и полям необходимо добавить комментарии. Используйте предложение комментария, чтобы добавить примечания к таблицам и столбцам с самого начала Просто поддерживайте словарь данных.
4. Постарайтесь максимально контролировать размер данных отдельной таблицы. Рекомендуется контролировать его в пределах 5 миллионов. 5 миллионов не являются ограничением для базы данных MySQL. Если он слишком большой, это вызовет большие проблемы с изменением структуры таблицы, резервным копированием и восстановлением. Используйте архивирование исторических данных (применяется к данным журнала), под-базу данных и подтаблицу (применяется к бизнес-данным) для управления объемом данных.
5. Используйте таблицу разделов MySQL с осторожностью. Таблица
разделов физически представлена ​​в виде нескольких файлов и представлена ​​в логическом виде. Тщательно выбирайте ключ раздела для таблицы. Эффективность запроса между разделами может быть ниже. Рекомендуется управлять большими данными, физически разделяя таблицу.
6. Максимально разделяйте горячие и холодные данные. Уменьшите ширину таблицы.
MySQL ограничивает каждую таблицу до 4096 столбцов. И размер каждой строки данных не может превышать 65535 байт. Уменьшите количество операций ввода-вывода на диске, чтобы обеспечить частоту попадания горячих данных в кеш-память (чем шире таблица, тем больше памяти занимает, когда таблица загружается в буферный пул памяти, и она будет потреблять больше IO) Более эффективное использование кеша, чтобы избежать чтения бесполезных холодных данных, часто используемых вместе, в таблицу (чтобы избежать большего количества связанных операций)
7, запретить создание зарезервированных полей в таблице
Именование зарезервированных полей затрудняет распознавание имен. Зарезервированные поля не могут подтвердить сохраненный тип данных, поэтому невозможно выбрать соответствующий тип для изменения типа зарезервированного поля, и таблица будет заблокирована.
8. Запрещается хранить изображения в базе данных , Файл и другие большие двоичные данные
обычно представляют собой большие файлы, которые вызывают быстрый рост данных за короткий период времени. Когда база данных считывается из базы данных, обычно выполняется большое количество случайных операций ввода-вывода. Когда файл большой, операции ввода-вывода занимают много времени и обычно хранятся На файловом сервере в базе данных хранится только информация об адресе файла
9. Запрещается проводить стресс-тестирование базы данных в Интернете
10. Запрещается напрямую подключаться к базе данных среды из среды разработки и среды тестирования.

В-третьих, спецификации дизайна поля базы данных
1. Предпочтительно выбирать наименьший тип данных, который соответствует потребностям хранения. Чем больше поле столбца
причины
, тем больше места требуется для индексации, поэтому количество узлов индекса, которые могут быть сохранены на странице Чем меньше и меньше количество операций ввода-вывода требуется во время обхода, тем хуже производительность индекса
. Метод
1) Преобразование строки в числовой тип для хранения, например: Преобразование IP-адреса в пластиковые данные .

MySQL предоставляет два метода работы с IP-адресами:

Перед вставкой данных используйте inet_aton для преобразования IP-адреса в целое число, что может сэкономить место. При отображении данных используйте inet_ntoa для преобразования целочисленного IP-адреса в отображение адреса.

2) Для неотрицательных данных (таких как самоинкрементирующийся идентификатор, целочисленный IP-адрес), целое число без знака является предпочтительным для хранения,
потому что: unsigned может удвоить пространство хранения по сравнению со знаком

N в VARCHAR (N) представляет количество символов, а не количество байтов.

Используйте UTF8 для хранения 255 китайских символов. Varchar (255) = 765 байт. Чрезмерная длина потребляет больше памяти.
2. Избегайте использования типов данных TEXT и BLOB. Наиболее распространенный тип TEXT может хранить 64 КБ данных
. Рекомендуется разделить столбцы BLOB или TEXT в отдельную расширенную таблицу.
Временная таблица памяти MySQL не поддерживает Поддерживает большие типы данных, такие как TEXT и BLOB. Если такие данные включены в запрос, временные таблицы в памяти не могут использоваться в таких операциях, как сортировка, и необходимо использовать временные таблицы на диске.
И для этого типа данных Mysql все равно должен выполнить второй запрос, что сильно снизит производительность sql, но это не означает, что такие типы данных не должны использоваться.
Если вы должны его использовать, рекомендуется разделить столбец BLOB или TEXT в отдельную расширенную таблицу. Не используйте select * при запросе. Вам нужно только получить необходимые столбцы. Не запрашивайте столбец, если вам не нужны данные в столбце TEXT.
· Типы TEXT или BLOB могут использовать только префиксные индексы.
Поскольку MySQL имеет ограничения на длину полей индекса, типы TEXT могут использовать только префиксные индексы, а для столбцов TEXT не может быть значений по умолчанию.
3. Избегайте использования типа ENUM
· Изменение значения ENUM требует использования оператора ALTER
· Операция ORDER BY типа ENUM неэффективна и требует дополнительных операций
· Запрещено использовать числовые значения в качестве значения перечисления ENUM
4. Попробуйте определить все столбцы как NOT NULL
причины:
· Столбец Index NULL требует дополнительного места для сохранения, поэтому он занимает больше места;
· Значение NULL следует обрабатывать специально при сравнении и вычислении
5. Используйте тип TIMESTAMP (4 байта) или DATETIME (8 слов) Раздел) время хранения
TIMESTAMP хранит временной диапазон 1970-01-01 00:00:01 ~ 2038-01-19-03: 14: 07.
TIMESTAMP занимает 4 байта и совпадает с INT, но более читается, чем INT
. Тип DATETIME используется для хранения, которое превышает диапазон значений TIMESTAMP.
Люди часто используют строки для хранения данных типа даты (неправильная практика):
· Недостаток 1: невозможно использовать функции даты для вычисления и сравнения
· Недостаток 2: использование строки для хранения дат занимает больше места
6. Связано с финансами Данные количества должны использовать десятичный тип.
· Неточная плавающая точка: https://blog.csdn.net/shkfpwzfloat,double
· Точная плавающая точка: десятичный
тип Decimal - это точное число с плавающей запятой, которое не потеряет точность во время вычисления. Занимаемое пространство определяется заданной шириной: каждые 4 байта могут хранить 9 цифр, а десятичная точка занимает один байт. Может использоваться для хранения целочисленных данных большего размера, чем bigint.

В-четвертых, спецификации дизайна индексов
1. Ограничьте количество индексов в каждой таблице.Рекомендуется, чтобы индекс отдельной таблицы не превышал 5
индексов, не больше, тем лучше! Индексы могут повысить эффективность, а также снизить эффективность.
Индексы могут повысить эффективность запросов, но также снизить эффективность вставок и обновлений и даже в некоторых случаях снизить эффективность запросов.
Потому что, когда оптимизатор mysql выбирает, как оптимизировать запрос, он оценивает каждый индекс, который может использоваться, в соответствии с единой информацией для создания наилучшего плана выполнения.Если существует много индексов одновременно, они могут использоваться для запроса. Это увеличит время, необходимое оптимизатору mysql для создания плана выполнения, а также снизит производительность запросов.
2. Запрещено создавать отдельный индекс для каждого столбца в таблице.
До версии 5.6 один SQL мог использовать только один индекс в таблице. После 5.6, хотя существует метод оптимизации для объединения индексов, он далек от использования одного Метод запроса объединенного индекса хорош.
3. Каждая таблица Innodb должна иметь первичный ключ.
Innodb - это таблица, организованная по индексу: логический порядок хранения данных и порядок индекса одинаковы.
Каждая таблица может иметь несколько индексов, но может быть только один порядок хранения таблицы. Innodb организует таблицу в порядке индекса первичного ключа.
Не используйте часто обновляемые столбцы в качестве первичных ключей и не применяйте первичные ключи с несколькими столбцами (эквивалент объединенного индекса). Не используйте столбцы UUID, MD5, HASH или строковые столбцы в качестве первичных ключей (последовательный рост данных не может быть гарантирован).
Рекомендуется использовать значение идентификатора автоинкремента для первичного ключа.

Пять общих предложений столбцов индекса
· Столбцы, которые появляются в предложении WHERE операторов SELECT, UPDATE и DELETE
· Поля, включенные в ORDER BY, GROUP BY и DISTINCT Не
создавайте индекс для столбцов, которые соответствуют полям в 1 и 2 , Обычно лучше установить объединенный индекс для полей в 1, 2
· Связанный столбец соединения нескольких таблиц

6. Как выбрать порядок столбцов индекса
Целью индексирования является поиск данных по индексу, уменьшение количества случайных операций ввода-вывода и повышение производительности запросов.Чем меньше данных может отфильтровать индекс, тем меньше данных будет считано с диска. .
· Наивысшая степень дискриминации помещается в крайнюю левую часть комбинированного индекса (дискриминация = количество различных значений в столбце / общее количество
строк в столбце ); Чем меньше, тем больше объем данных, который может быть сохранен на странице, и тем выше производительность ввода-вывода);
· Наиболее часто используемые столбцы размещаются с левой стороны объединенного индекса (так что можно построить меньше индексов).

В-седьмых, избегайте создания избыточных индексов и повторяющихся индексов,
поскольку это увеличит время, необходимое оптимизатору запросов для создания плана выполнения.
· Примеры повторяющихся индексов: первичный ключ (id), индекс (id), уникальный индекс (id)
· Примеры избыточных индексов: index (a, b, c), index (a, b), index (a)

Восьмой, отдайте приоритет покрывающему индексу.
Для частых запросов отдайте приоритет использованию покрывающего индекса.
Покрывающий индекс: это индекс, покрывающий индекс, который содержит все поля запроса (поля, включенные в where, select, ordery by, group by)
:
· Избегайте вторичных запросов индексации таблиц
Innodb. Innodb хранится в порядке кластеризованного индекса. Для Innodb вторичный индекс, хранящийся в листовом узле, является информацией о первичном ключе строки.Если
вы используете вторичный индекс для запроса данных, после нахождения соответствующего значения ключа вы должны выполнить вторичный запрос по первичному ключу. Получите данные, которые нам действительно нужны. В покрывающем индексе все данные могут быть получены из значения ключа вторичного индекса, что позволяет избежать вторичных запросов по первичному ключу, сократить количество операций ввода-вывода и повысить эффективность запросов.
· Случайный ввод-вывод можно превратить в последовательный ввод-вывод для повышения эффективности запросов.
Поскольку индекс покрытия хранится в порядке значений ключей, для поиска диапазона с интенсивным вводом-выводом он намного меньше ввода-вывода, чем чтение каждой строки данных с диска случайным образом, поэтому Покрывающий индекс также может использоваться для преобразования операций ввода-вывода произвольного чтения с диска в последовательные операции ввода-вывода поиска по индексу во время доступа.

Девять, спецификация набора индекса
пытается избежать использования ограничений внешнего ключа.
· Не рекомендуется использовать ограничения внешнего ключа (внешний ключ), но необходимо установить индекс на связанный ключ между таблицей и таблицей;
· Внешние ключи могут использоваться для обеспечения ссылочной целостности данных , Но рекомендуется реализовать на бизнес-стороне;
Внешние ключи будут влиять на операции записи родительской таблицы и дочерней таблицы, тем самым снижая производительность.

X. Спецификации разработки SQL базы данных
1. Рекомендуется использовать подготовленные операторы для операций с базой данных.
Подготовленные операторы могут повторно использовать эти планы, сократить время, необходимое для компиляции SQL, а также решить проблему внедрения SQL, вызванную динамическим SQL. Передавать только параметры. Более эффективно, чем передача операторов SQL. Один и тот же оператор можно анализировать один раз и использовать несколько раз для повышения эффективности обработки.
2. Избегайте неявного преобразования типов данных: неявное
преобразование приведет к сбою индекса. Например: выберите имя, телефон у клиента, где id = '111';
3. Полностью используйте существующие индексы в таблице.
Избегайте использования условий запроса с двойным%.
Например, подобное «% 123%» (если нет начального%, только конечный%, можно использовать индекс столбца)
· SQL может использовать только один столбец в составном индексе для запроса диапазона,
такого как: , b, c столбцы объединенного индекса, в условии запроса есть запрос диапазона столбца a, индекс столбцов b и c не будет использоваться при определении объединенного индекса, если столбец a должен использоваться для поиска диапазона В этом случае поместите столбец a справа от индекса соединения.
Используйте левое соединение или не существует, чтобы оптимизировать не в работе,
потому что not in обычно использует ошибку индекса.
4. При проектировании базы данных вы должны учитывать будущее расширение.
5. Программа подключается к разным базам данных и использует разные учетные записи и запросы между базами данных в цифрах.
Оставьте место для миграции базы данных и вложенных таблиц базы данных
. Уменьшите взаимосвязь между бизнесом
. Избегайте разрешений. Угрозы безопасности, вызванные чрезмерным размером
6. Запрещено использовать SELECT * Вы должны использовать SELECT <список полей>.
Причины для запроса :
· Потребление большего количества ресурсов ЦП, ввода-вывода и пропускной способности сети
· Невозможно использовать покрывающий индекс
· Может снизить влияние изменений структуры таблицы
7. Запрещается использовать операторы INSERT без списков полей,
таких как: вставить в значения ('a', 'b', 'c');
следует использовать вставку в t (c1, c2, c3) values ​​('a', 'b', 'c');
8. Избегайте использования подзапросов. Вы можете оптимизировать подзапросы в операции соединения.
Обычно подзапросы находятся в разделе in и в подзапросе Только когда это простой SQL (не включает предложения union, group by, order by и limit), подзапрос можно преобразовать в связанный запрос для оптимизации.
Причины низкой производительности подзапроса:
· Набор результатов подзапроса не может использовать индекс. Обычно набор результатов подзапроса сохраняется во временной таблице. Во временной таблице памяти или на диске не будет индекса, поэтому производительность запроса будет снижена. Определенное влияние;
· Особенно для подзапросов, которые возвращают относительно большой набор результатов, тем сильнее влияние на производительность запроса;
· Поскольку подзапросы будут генерировать большое количество временных таблиц без индексов, они будут потреблять слишком много ресурсов ЦП и Ресурсы ввода-вывода генерируют множество медленных запросов.
9. Избегайте использования JOIN для связывания слишком большого количества таблиц.
Для Mysql существует связанный кеш. Размер кеша можно установить с помощью параметра join_buffer_size.
В Mysql, если вы присоединяетесь к одной таблице для того же SQL, будет выделен еще один кеш ассоциаций.Если в SQL связано больше таблиц, тем больше будет занимаемая память.
Если в программе используется большое количество операций сопоставления нескольких таблиц и параметр join_buffer_size не является разумным, легко вызвать переполнение памяти сервера, что повлияет на стабильность производительности базы данных сервера.
В то же время для операций связывания будут выполняться операции с временными таблицами, влияющие на эффективность запросов.Mysql позволяет связать до 61 таблицы, и рекомендуется не более 5.
10. Уменьшите количество взаимодействий с базой данных. База
данных больше подходит для обработки пакетных операций и объединения нескольких идентичных операций вместе, что может повысить эффективность обработки.
11. При выполнении или суждениях, соответствующих одному и тому же столбцу,
значение in вместо или in не должно превышать 500 операций Индексы можно использовать более эффективно, или в большинстве случаев индексы используются редко.
12. Запрещается использовать функцию order by rand () для случайной сортировки, которая
загрузит все подходящие данные в таблице в память, а затем отсортирует все данные в памяти в соответствии со случайно сгенерированным значением и может генерировать по одному для каждой строки. Случайные значения: если набор данных, отвечающий условиям, очень велик, он потребляет много ресурсов ЦП, ввода-вывода и памяти.
Рекомендуется получить случайное значение в программе, а затем получить данные из базы данных
13. Предложение WHERE запрещает преобразование функций и вычисление
столбца.Индекс не может использоваться, когда преобразование функции или вычисление выполняется для столбца.
· Не рекомендуется:

· Рекомендация:

14. Используйте UNION ALL вместо UNION, когда очевидно, что не будет повторяющихся значений
. UNION поместит все данные двух наборов результатов во временную таблицу перед выполнением операций дедупликации
. UNION ALL больше не будет дедуплицировать набор результатов. Операция
15. Разделение сложного большого SQL на несколько маленьких SQL
· Большой SQL: логически более сложный и требует большого количества ЦП для вычислений
· MySQL: один SQL может использовать только один ЦП для вычислений
· Разделение SQL может пройти Параллельное выполнение для повышения эффективности обработки

11. Правила поведения при работе с базой данных
1. Операции пакетной записи (UPDATE, DELETE, INSERT) более 1 миллиона строк должны выполняться несколько раз в
пакетном режиме. Большие пакетные операции могут вызвать серьезные задержки между ведущим и ведомым устройством
. Пакетные операции могут вызвать серьезные задержки между ведущим и ведомым устройством. Для крупномасштабных операций записи обычно требуется определенное количество времени. Только когда выполнение в главной библиотеке будет завершено, оно будет выполняться в других ведомых библиотеках, поэтому это вызовет ведущую библиотеку и ведомое устройство. Долгосрочная задержка библиотеки
· Когда журнал binlog находится в строчном формате, будет создано большое количество журналов.
Операции большой пакетной записи будут генерировать множество журналов, особенно для двоичных данных в формате строки. Поскольку формат строки будет записывать изменение каждой строки данных, Чем больше данных мы модифицируем за раз, тем больше журналов будет создано и тем больше времени потребуется для передачи и восстановления журналов.Это также является причиной задержки ведущего-ведомого.
· Избегайте крупных транзакционных операций для
изменения данных в больших количествах. Это должно выполняться за одну транзакцию. Это приведет к блокировке большого количества данных в таблице, что приведет к большому количеству блокировок, что окажет очень большое влияние на производительность MySQL.
В частности, долговременная блокировка заполнит все доступные подключения к базе данных, из-за чего другие приложения в производственной среде не смогут подключиться к базе данных, поэтому обязательно обратите внимание на операции пакетной записи.
2. Используйте pt-online-schema-change, чтобы изменить структуру таблицы
для больших таблиц. Избегайте задержек "главный-подчиненный", вызванных большими модификациями таблиц
. Избегайте блокировки таблиц при изменении полей таблицы. Вы
должны быть осторожны при изменении структур данных больших таблиц. Нельзя допускать серьезных операций блокировки таблицы, особенно в производственной среде.
pt-online-schema-change он сначала создаст новую таблицу с той же структурой, что и исходная таблица, и изменит структуру таблицы в новой таблице, а затем скопирует данные из исходной таблицы в новую таблицу и в исходную таблицу Добавьте несколько триггеров.
Скопируйте только что добавленные данные из исходной таблицы в новую таблицу. После копирования всех данных в строке новая таблица получает имя исходной таблицы, а исходная таблица удаляется.
Разложите исходную операцию DDL на несколько небольших пакетов.
3. Запрещается предоставлять суперразрешение учетной записи, используемой программой.
Когда достигается максимальное количество подключений, пользователь с супер-разрешением также запускается для подключения. Супер-разрешение может быть зарезервировано только для учетной записи, используемой администратором баз данных для решения проблемы.
4. Чтобы
программа могла подключиться к учетной записи базы данных, следуйте принципу минимальных прав. Учетная запись базы данных, используемая программой, может использоваться только в одной БД. Учетные записи, которые не могут использоваться программами, работающими с несколькими базами данных, в принципе не могут иметь права на удаление.