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

Когда мы разрабатываем решения в области технологий баз данных, есть ли у нас собственные концепции и принципы проектирования, или мы проектируем больше, основываясь на нашей собственной интуиции? Сожалели ли мы когда-нибудь о низкоуровневом сбое, произошедшем в сети? Может быть, мы сможем избежать этого, проявив немного внимания? Вы когда-нибудь задумывались о том, как этого избежать? Ценность следующих норм - это всего лишь контрольный список для нашей работы. Нам необходимо накапливать эффективный опыт на ошибках, чтобы направлять будущую работу. Следующие спецификации были полностью проверены в крупных интернет-компаниях и особенно подходят для бизнес-сценариев с большим параллелизмом и большими объемами данных. Первое, что нужно представить, — это спецификация безопасности, потому что безопасность — это немаловажный вопрос. Многие компании причинили болезненные потери пользователям из-за утечки собственных данных, поэтому они ставят спецификацию безопасности на первое место.

1. Характеристики безопасности

1. [Обязательно] Запрещено хранить пароли в открытом виде в базе данных, пароли должны храниться после шифрования. Примечание. Для операций шифрования рекомендуется, чтобы команда промежуточного программного обеспечения компании предоставила единый алгоритм шифрования и управление ключами на основе таких расширений, как как и мибатис, чтобы избежать каждого Бизнес-направление разрабатывается отдельно, и оно также оторвано от конкретного бизнеса

2. [Обязательно] Запрещается хранить конфиденциальную информацию пользователя в базе данных в открытом виде, например, номер мобильного телефона и т. д. Примечание. Для номеров мобильных телефонов компании рекомендуется создать единую службу запроса номеров мобильных телефонов для избегайте хранения их отдельно в каждом бизнес-направлении

3. [Обязательно] Запрещено напрямую экспортировать или запрашивать данные, относящиеся к конфиденциальной информации пользователя для студентов-бизнесменов. При необходимости это должно быть одобрено руководителем.

4. [Обязательно] Операции, включающие функцию экспорта данных, например конфиденциальные поля, должны быть зашифрованы или десенсибилизированы.

5. [Обязательно] Журналы аудита необходимы для операций с конфиденциальными данными, связанных с взаимодействием с базой данных, и при необходимости требуются оповещения.

6. [Обязательно] Для IP-адресов, подключенных к базе данных, должна быть установлена функция белого списка, чтобы предотвратить незаконный доступ к IP-адресам.

7. [Обязательно] Частота или количество посещений важного SQL-запроса (например, запросов информации о заказе) должны отслеживаться исторически, чтобы вовремя обнаружить аномальное поведение.

8. [Рекомендация] Рекомендуется регулярно менять имя пользователя и пароль для подключения к онлайн-базе данных.

2. Основные характеристики

1. [Рекомендация] Старайтесь не выполнять расчеты в базе данных, для завершения сложные расчеты необходимо перенести в бизнес-приложения.

2. [Рекомендация] Отклоняйте большие операторы sql, большие транзакции и большие пакеты, которые могут быть переданы бизнес-стороне для завершения.

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

3. [Рекомендация] Избегайте использования хранимых процедур, триггеров, функций и т. д., которые могут легко привести к связыванию бизнес-логики с БД.

Объяснение: База данных хорошо хранится и индексируется. Чтобы освободить ЦП базы данных, перенести вычисления на уровень обслуживания, а также обеспечить лучшую масштабируемость. 4. [Обязательно] Таблицы данных и поля данных должны быть добавлены с китайскими аннотациями.

Пояснение: Увидев ее, учащиеся, которые будут ее обслуживать, поймут, для чего нужна эта таблица.

5. [Обязательно] Не храните в базе данных большие данные, такие как изображения и файлы.

Примечание. Большие файлы и изображения необходимо хранить в файловой системе.

6. [Рекомендация] Следуйте принципу минимальных привилегий для программ, подключающихся к учетным записям базы данных.

7. [Рекомендация] При проектировании базы данных вам необходимо спросить себя, учли ли вы будущую масштабируемость.

8. [Рекомендация] Используйте pt-query-digest для регулярного анализа журнала медленных запросов и его оптимизации.

9. [Рекомендация] Используйте доменное имя интрасети вместо IP-адреса для подключения к базе данных.

10. [Рекомендация] Если объем данных или рост данных относительно велик на раннем этапе планирования, то стратегию подтаблицы следует добавить в обзор проекта.

11. [Рекомендация] Все ключевые слова R&D SQL должны быть в нижнем регистре, для каждого слова допускается только один пробел.

3. Соглашение об именах

1. [Обязательно] Имена библиотек, имена таблиц и имена полей должны быть в нижнем регистре, с подчеркиванием и длиной не более 32 символов. Они должны быть понятны из названия. Вместо глаголов рекомендуется использовать существительные. Значение слов. связано с бизнесом, продуктовой линейкой и т. д. Пиньинь запрещена, смешанный английский

2. [Обязательно] Обычный формат именования индексов: idx_имя_таблицы_имя поля индекса (если существует несколько индексов с именем первого поля, вы можете добавить второе имя поля, если оно слишком длинное, вы можете использовать сокращение), формат уникального имени индекса. : uk_table name_index имя поля (имя индекса должно быть в нижнем регистре, если длина слишком длинная, вы можете использовать сокращение), имя индекса первичного ключа: pk_ имя поля

3. [Обязательно] Запрещено использование зарезервированных слов MySQL в имени библиотеки, имени таблицы и имени поля.

4. [Обязательно] Имя таблицы временной библиотеки должно иметь префикс tmp и суффикс даты.

5. [Обязательно] Таблица резервной копии базы данных должна иметь префикс bak и суффикс даты.

6. [Рекомендация] Используйте HASH для разброса таблицы, суффикс имени таблицы использует шестнадцатеричное число, а нижний индекс начинается с 0.

7. [Рекомендация] Подтаблицы по дате и времени должны соответствовать формату ГГГГ[ММ][ДД][ЧЧ]

8. [Рекомендация] Если таблица разброса использует md5 (или аналогичный алгоритм хеширования) для разброса таблицы, используйте шестнадцатеричный суффикс имени таблицы, например user_ff.

9. [Рекомендация] Для разброса таблиц используйте остаток CRC32 (или аналогичный арифметический алгоритм). Суффикс имени таблицы должен быть числом. Число должно начинаться с 0 и иметь одинаковую ширину.

10. [Рекомендация] При использовании таблицы с распределением по времени суффикс имени таблицы должен иметь определенный формат, например user_20110209 для таблицы с распределением по дням и user_201102 для таблицы с распределением по месяцам.

11. [Обязательно] Поля, которые выражают понятие «да» или «нет», для названия используйте _ xxx.

4. Спецификации проекта библиотеки

1. [Рекомендация] В базе данных используется механизм хранения InnoDB.

Описание: Поддержка транзакций, блокировок на уровне строк, повышение производительности одновременного выполнения, оптимизация страниц кэша ЦП и памяти для более эффективного использования ресурсов.

2. [Рекомендация] Единообразно используйте UTF8 для наборов символов баз данных и таблиц.

Объяснение: utf8 известен как универсальный код, который не требует перекодирования, не содержит риска искажения символов и экономит место. Если есть поле, в котором необходимо хранить выражения эмодзи, установите для таблицы или поля значение utf8mb4, и utf8mb4 обратно совместим с utf8.

3. [Рекомендация] Используйте разные базы данных для разных предприятий, чтобы избежать взаимного влияния.

4. [Обязательно] Все онлайн-бизнес-библиотеки должны построить архитектуру высокой доступности MHA, чтобы избежать одноточечных проблем.

5. Характеристики конструкции стола

1. [Рекомендация] Пример спецификации создания таблицы

CREATE TABLE `student_info` (    
`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',    
`stu_name` varchar(10) NOT NULL DEFAULT '' COMMENT '姓名',    
`stu_score` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT '总分',    
`stu_num` int(11) NOT NULL COMMENT '学号',    
`gmt_create` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',    
`gmt_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',    
`status` tinyint(4) DEFAULT '1' COMMENT '1代表记录有效，0代表记录无效',      
PRIMARY KEY (`id`),      
UNIQUE KEY `uk_student_info_stu_num` (`stu_num`) USING BTREE,    
KEY `idx_student_info_stu_name` (`stu_name`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='学生信息表';

2. [Обязательно] Запретить использование внешних ключей, при наличии ограничений целостности внешних ключей требуется контроль приложений.

3. [Обязательно] Каждая таблица Innodb должна иметь первичный ключ.

Объяснение: Innodb — это таблица, организованная по индексу, и логический порядок хранения ее данных такой же, как и в индексе. Каждая таблица может иметь несколько индексов, но порядок хранения таблицы может быть только один.Innodb организует таблицы в соответствии с порядком индексов первичного ключа, поэтому не используйте часто обновляемые столбцы, такие как UUID, MD5, HASH и строковые столбцы, поскольку первичные ключи, эти столбцы не могут гарантировать последовательный рост данных, и для первичного ключа рекомендуется использовать значения идентификатора с автоинкрементом.

4. [Рекомендация] Число столбцов в одной таблице предпочтительно должно быть меньше 50.

5. [Обязательно] Запретить использование таблиц разделов.

Объяснение: Таблица разделов физически представлена в виде нескольких файлов, но логически она представлена как одна таблица. Тщательно выбирайте ключ раздела, эффективность межраздельных запросов может быть ниже. Рекомендуется управлять большими данными посредством физического разделения таблицы.

6. [Рекомендация] Разделите большие поля и поля с низкой частотой доступа и разделите горячие и холодные данные.

7. [Рекомендация] Примите соответствующую стратегию подбаз данных и подтаблиц, например десять таблиц в тысяче баз данных, сто таблиц в десяти базах данных и т. д. (рекомендуется, чтобы размер таблицы контролировался на уровне 2G).

8. [Рекомендация] Не более 50 полей int в одной таблице, не более 20 символьных полей, не более 2 текстовых полей.

9. [Рекомендуется] Настройки таблицы по умолчанию создают временную метку и изменяют поля временной метки.

10. [Рекомендация] Таблицы типа журнала можно рассматривать как горизонтально разрезанные в зависимости от времени создания, а исторические данные следует регулярно архивировать.

11. [Обязательно] Не используйте порядок с помощью rand().

Описание: заказ с помощью rand() добавит в таблицу псевдостолбец, а затем с помощью функции rand() вычислит значение rand() для каждой строки данных. На основе сортировки строк обычно создается временная таблица на диске, поэтому эффективность очень высокая Низкая.

12. [Ссылка] Вы можете использовать комбинацию хеша, диапазона и таблицы поиска для создания таблицы разброса.

13. [Рекомендация] Рекомендуется контролировать количество данных в каждой таблице ниже 5 миллионов. Если оно превышает 5 миллионов, это может быть достигнуто путем архивирования исторических данных или подбазы данных и подтаблицы (5 миллионов строк не являются лимит базы данных MySQL.Слишком большой - для изменения структуры таблицы, резервного копирования, Восстановление будет очень проблематичным. MySQL не имеет ограничения на хранилище, это зависит от настроек хранилища и файловой системы)

14. [Обязательно] Запрещено создавать зарезервированные поля в таблицах.

Объяснение: Именование зарезервированных полей трудно понять из названия. Зарезервированное поле не может подтвердить сохраненный тип данных, поэтому невозможно выбрать соответствующий тип; изменение типа зарезервированного поля приведет к блокировке таблицы.

6. Технические характеристики полевого проектирования

1. [Обязательно] Поле должно быть определено как NOT NULL и должно быть указано значение по умолчанию.

Объяснение: поля NULL сложно запрашивать и оптимизировать, индексы для полей NULL требуют дополнительного места, а составные индексы для полей NULL недействительны.

2. [Обязательно] Использование ENUM запрещено, вместо него можно использовать TINYINT.

3. [Обязательно] Запретить использование типов TEXT и BLOB (если количество записей в таблице меньше 10 000, можно рассмотреть)

4. [Обязательно] Вы должны использовать varchar(20) для хранения номера телефона.

5. [Обязательно] Запрещается использовать десятичные дроби для хранения национальной валюты и использовать в качестве единицы измерения «фен», чтобы в базе данных было целое число.

6. [Обязательно] Используйте DECIMAL вместо FLOAT и DOUBLE для хранения точных чисел с плавающей запятой.

7. [Рекомендация] Используйте UNSIGNED для хранения неотрицательных целых чисел.

Объяснение: Число байт одинаковое, диапазон сохраняемых значений больше.

8. [Рекомендация] Для хранения IPV4 рекомендуется использовать INT UNSIGNED.

Примечание. Использование UNSINGED INT для хранения IP-адреса занимает 4 байта, а CHAR(15) — 15 байт. Кроме того, компьютеры обрабатывают целочисленные типы быстрее, чем строковые. Используйте INT UNSIGNED вместо CHAR(15) для хранения адреса IPV4 и преобразуйте его с помощью функций MySQL inet_ntoa и inet_aton. В настоящее время не существует функции преобразования адресов IPv6, и их необходимо хранить с использованием DECIMAL или двух BIGINT. Например: SELECT INET_ATON('192.168.172.3'); 3232279555 SELECT INET_NTOA(3232279555); 192.168.172.3

9. [Рекомендация] Длина поля должна быть распределена в соответствии с фактическими потребностями, насколько это возможно, и не выделять большую емкость по желанию.

10. [Рекомендация] Количество полей основной таблицы должно быть как можно меньшим, а большие поля следует рассматривать для разделения.

11. [Рекомендация] Правильно рассмотрите некоторые антипарадигмальные конструкции таблиц, увеличьте количество избыточных полей и сократите JOIN.

12. [Рекомендация] Рассмотрите возможность объединения *100 как целого числа в поле фонда и избегайте использования десятичного типа хранения с плавающей запятой.

13. [Рекомендация] Используйте VARBINARY для хранения чувствительных к регистру строк переменной длины или двоичного содержимого. Описание: VARBINARY по умолчанию чувствителен к регистру, не имеет концепции набора символов и работает быстро.

14. [Справка] Тип INT постоянно занимает 4 байта для хранения. Описание: INT(4) означает только, что ширина отображаемого символа составляет 4 бита, а не длина хранения. Число в круглых скобках числового типа указывает только ширину и не имеет ничего общего с диапазоном хранения. Например, INT(3) по умолчанию отображает 3 цифры, заполняет пробелы и отображается нормально, когда оно превышается. Python, Java клиенты и т. д. не имеют этой функции

15. [Ссылка] Используйте DATETIME и TIMESTAMP по-разному.

Примечание. Используйте тип YEAR для хранения года, тип DATE для хранения даты и тип TIMESTAMP для хранения времени (с точностью до секунд). И DATETIME, и TIMESTAMP имеют точность до секунды, и TIMESTAMP предпочтительнее, поскольку TIMESTAMP имеет только 4 байта, тогда как DATETIME имеет 8 байтов, а TIMESTAMP имеет характеристики автоматического назначения и автоматического обновления. Дополнение: Как использовать атрибут автоматического назначения TIMESTAMP? Автоматически инициализируется и автоматически обновляется: столбец 1 TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATECURRENT_TIMESTAMP инициализируется только автоматически: столбец 1 TIMESTAMP DEFAULT CURRENT_TIMESTAMP автоматически обновляется, и инициализированное значение равно 0: столбец 1 TIMESTAMP DEFAULT 0 ON UPDATE Инициализированное значение CURRENT_TIMESTAMP 0: столбец 1 TIMESTAMP DEFAULT 0

16. [Рекомендация] Разделите большие поля и поля с низкой частотой доступа на отдельные таблицы для хранения и разделите горячие и холодные данные.

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

17. [Ссылка] VARCHAR(N), N означает количество символов, а не количество байтов, например VARCHAR(255), который может хранить до 255 китайских символов, и N необходимо выбирать в соответствии с фактической шириной.

18. [Ссылка] VARCHAR(N), N должно быть как можно меньше, поскольку максимальная длина всех полей VARCHAR в таблице MySQL составляет 65535 байт, а длина N будет использоваться для операций с памятью, таких как сортировка и создание временных таблицы Применить к памяти

19. [Рекомендация] VARCHAR(N), если N>5000, используйте тип BLOB.

20. [Рекомендация] Используйте короткие типы данных, например, если диапазон значений составляет 0–80, используйте TINYINT UNSIGNED.

21. [Обязательно] статус магазина, пол и т.д., используйте TINYINT

22. [Обязательно] Все имена столбцов и типы столбцов, в которых хранятся одни и те же данные, должны быть согласованными (поля в нескольких таблицах, такие как user_id, должны быть одного типа).

23. [Рекомендация] Отдавайте приоритет выбору наименьшего типа данных, отвечающего потребностям хранения.

24. [Рекомендация] Если длины хранимых строк практически равны, используйте тип строки фиксированной длины char.

7. Спецификации дизайна индекса

1. [Рекомендация] Рекомендуется ограничить количество однотабличных индексов до менее 5.

Объяснение: Индексы могут повысить эффективность запросов, но они также снизят эффективность вставки и обновления, а в некоторых случаях даже снизят эффективность запросов, поэтому чем больше, тем лучше.

2. [Обязательно] Запрещено создавать индексы по атрибутам, которые часто обновляются и имеют низкую дискриминацию.

3. [Обязательно] Для создания комбинированного индекса поля с высокой дискриминацией должны располагаться впереди

4. [Рекомендация] Используйте индексы для строк. Если длина определения строки превышает 128, вы можете рассмотреть префиксный индекс.

5. [Обязательно] Таблица должна иметь первичный ключ, и он должен быть auto_increment, а не null. Определите беззнаковые tinyint, smallint, int, bigint в соответствии с фактической ситуацией в таблице.

6. [Обязательно] Запретить часто обновляемые столбцы в качестве первичных ключей.

7. [Обязательно] Запретить строковые столбцы в качестве первичных ключей.

8. [Обязательно] Запретить UUID MD5 HASH в качестве первичного ключа (значение слишком дискретное)

9. [Рекомендация] Используйте непустой уникальный ключ в качестве первичного ключа по умолчанию.

10. [Рекомендация] Для первичного ключа рекомендуется выбрать автоинкремент или генератор чисел.

11. [Рекомендация] Core SQL отдает приоритет покрытию индексов.

12. [Ссылка] Избегайте избыточных и повторяющихся индексов.

13. [Ссылка] Индекс должен всесторонне оценивать плотность и распределение данных, а также учитывать соотношение запросов и обновлений.

14. [Обязательно] Не выполнять математические операции и функциональные операции над индексными столбцами.

15. [Рекомендация] В отделе исследований и разработок следует часто использовать объяснение. Если вы обнаружите, что избирательность индекса плохая, вы должны научиться использовать подсказку.

16. [Рекомендация] Если вы можете использовать уникальный индекс, вы должны использовать уникальный индекс для повышения эффективности запросов.

17. [Рекомендация] Для операторов с повторяющимися полями измените порядок полей условий операторов и создайте для него совместный индекс, чтобы уменьшить количество индексов.

18. [Обязательно] Должно быть гарантировано, что поле индекса не равно NULL, и следует учитывать значение по умолчанию. NULL также занимает место, а NULL сильно влияет на эффективность запросов индексов.

19. [Обязательно] Вновь созданный уникальный индекс не может быть продублирован с помощью первичного ключа.

20. [Рекомендация] Старайтесь не использовать внешние ключи и внешние ключи для защиты ссылочной целостности. Это можно реализовать на стороне бизнеса , чтобы избежать взаимного влияния на операции родительской и дочерней таблиц, снижая удобство использования.

21. [Обязательно] Строки не должны использоваться в качестве первичных ключей.

22. [Обязательно] Таблица должна иметь самоинкрементирующий первичный ключ беззнакового типа int, который соответствует полю id в таблице.

Объяснение: Причина, по которой должен быть первичный ключ: для репликации используется режим RBR, а удаление таблицы без первичного ключа приведет к заполнению резервной базы данных; причина использования автоинкремента: запись данных может улучшить производительность вставки, избежать разделения страниц и уменьшить фрагментацию таблицы

23. [Рекомендация] При индексировании слишком длинного поля VARCHAR добавьте хеш-поле crc32 или MD5 для индексации хэш-поля.

Описание. Добавьте столбец url_crc32 в таблицу ниже, а затем создайте индекс на основе url_crc32, чтобы уменьшить длину поля индекса и повысить эффективность. CREATE TABLE url( ... url VARCHAR(255) NOT NULL DEFAULT 0, url_crc32 INT UNSIGNED НЕ NULL ПО УМОЛЧАНИЮ 0, .. .index idx_url(url_crc32) )

24. [Рекомендация] Неэквивалентные условия (IN, BETWEEN, <, <=, >, >=) в условии WHERE приведут к тому, что следующие условия не будут использовать индекс.

25. [Рекомендация] Порядок индексных полей должен учитывать количество значений полей после дедупликации и ставить большее число впереди.

26. [Рекомендация] Поля ORDER BY, GROUP BY и DISTINCT необходимо добавлять после индекса.

27. [Ссылка] Разумно создайте совместный индекс (во избежание избыточности), например (a,b,c) эквивалентен (a), (a,b), (a,b,c)

28. [Рекомендация] Количество полей в составном индексе не должно превышать 5.

29. [Обязательно] Не создавайте индексы по столбцам с низкой избирательностью, таким как «пол», «статус», «тип».

30. [Рекомендация] Если вы не можете перейти к индексу для одного условия, вы можете использовать Force –index, чтобы принудительно использовать указанный индекс.

31. [Обязательно] Запрещается создавать отдельный индекс для каждого столбца таблицы.

32. [Рекомендация] При создании индекса для поля varchar необходимо указать длину индекса. Нет необходимости создавать индекс для всего поля, длина индекса может быть определена в соответствии с фактической дискриминацией текста.

Восьмое, спецификация использования SQL

1. [Обязательно] Запретить использование SELECT *, получить только необходимые поля, необходимо отобразить атрибут столбца описания

Описание: Получение по запросу позволяет снизить потребление пропускной способности сети, позволяет эффективно использовать индекс покрытия, а изменение структуры таблицы практически не влияет на программу.

2. [Обязательно] Запрещено использовать INSERT INTO t_xxx VALUES(xxx), при этом должны отображаться указанные атрибуты вставленного столбца.

3. [Обязательно] Соответствующий тип должен использоваться в условии WHERE, чтобы избежать неявного преобразования типов MySQL.

Объяснение: После того, как MySQL выполнит неявное преобразование типа, он может преобразовать тип поля индекса в тип значения справа от знака =, в результате чего индекс не будет использоваться. Причина аналогична отказу от использования функций в поле индекса. В примере выберите uid из t_user, где телефон = 15855550101 (телефон имеет тип varchat, в настоящее время в запросе используются цифры, что приведет к сбою индекса)

4. [Обязательно] Запрещено использование функций или выражений над атрибутами условия WHERE.

5. [Обязательно] Запрещены отрицательные запросы и нечеткие запросы, начинающиеся с %.

6. [Обязательно] Приложение должно перехватывать исключения SQL и обрабатывать их соответствующим образом.

7. [Рекомендация] Сделайте оператор sql максимально простым, найдите способ разделить большой оператор sql на небольшие операторы sql.

Описание: Простой SQL упрощает использование кэша запросов MySQL, сокращает время блокировки таблиц, особенно MyISAM, и может использовать многоядерный процессор.

8. [Рекомендация] Транзакция должна быть простой, а длина всей транзакции не должна быть слишком длинной.

9. [Обязательно] Избегайте математических операций или функциональных операций в базе данных (MySQL не очень хорош в математических операциях и логических суждениях, и легко объединить бизнес-логику и БД).

10. [Рекомендация] Переписать использование OR в SQL на использование IN() (эффективность или не такая высокая, как у in)

11. [Справочник] Значение, содержащееся в IN в операторе SQL, не должно быть слишком большим, а количество чисел в нем рекомендуется контролировать в пределах 1000.

12. [Рекомендация] обратите внимание на эффективность ограничения страниц. Чем больше предел, тем ниже эффективность. лимит можно переписать

Пояснение: Пример перезаписи: 1) Метод перезаписи 1 Задержка записи таблицы возврата выберите xx,xx from t t1, (выберите идентификатор из t где .... предел 10000,10) t2 где t1.id = t2.id 2) Метод перезаписи 2 выберите идентификатор из t предела 10000, 10; следует изменить на => выберите идентификатор из t, где идентификатор > 10000 предела 10;

13. [Рекомендация] Попробуйте использовать объединение всех вместо объединения.

14. [Ссылка] Избегайте использования JOIN больших таблиц.

15. [Рекомендация] Обновление данных следует разбивать и обновлять пакетами, не обновляйте слишком много данных за один раз.

16. [Рекомендация] Используйте разумные операторы SQL, чтобы уменьшить количество взаимодействий с базой данных.

17. [Ссылка] Обратите внимание на использование инструментов анализа производительности Sql объяснения/showprofile/mysqlsla.

18. [Рекомендация] Если вы можете использовать NOT IN, вам не нужен NOT IN. Слишком много подводных камней, и будут извлечены пустые и NULL.

19. [Рекомендация] Что касается запроса на разбивку на страницы, рекомендуется разумно использовать разбиение на страницы в программе для повышения эффективности. С подзапросом следует использовать больший предел и смещение.

20. [Обязательно] Запрещено выполнять большие запросы в базе данных.

21. [Обязательно] Запретить одному оператору SQL одновременно обновлять несколько таблиц.

22. [Рекомендация] Используйте COUNT(*) вместо COUNT(primary_key) и COUNT(1) при подсчете количества записей в таблице.

Объяснение: count( * ) будет считать строки со значениями NULL, но count(имя столбца) не будет считать строки со значениями NULL в этом столбце.

23. [Рекомендация] Используйте пакетную отправку для операторов INSERT (INSERT INTO tableVALUES(),(),()...), количество значений не должно быть слишком большим.

24. [Рекомендация] При получении большого объема данных рекомендуется получать данные пакетами. Каждый раз, когда количество полученных данных меньше 2000, набор результатов должен быть меньше 1M.

25. [Рекомендация] При разработке рекомендуется использовать структуру базы данных (например, mybatis) или подготовленный оператор, что может повысить производительность и избежать SQL-инъекций.

26. [Обязательно] Запретить запросы между базами данных (оставьте место для миграции данных и подтаблиц подбазы данных, уменьшите связанность и уменьшите риск).

27. [Рекомендация] Старайтесь избегать использования подзапроса и оптимизируйте подзапрос как операцию соединения (результирующий набор подзапроса не может использовать индексы, и подзапрос будет генерировать временные табличные операции. Если объем данных подзапроса влияет на эффективность и потребляет слишком много ресурсов ЦП и ввода-вывода)

28. [Обязательное] Запрещено объединение более трех столов. (Типы данных полей, которые необходимо объединить, должны быть абсолютно согласованными; при запросе ассоциации с несколькими таблицами убедитесь, что связанные поля должны иметь индексы. Даже если две таблицы объединены, индекс таблицы и производительность SQL должны быть одинаковыми. обратил внимание.)

29. [Рекомендация] Цель оптимизации производительности SQL: как минимум достичь уровня диапазона, требованием является уровень ссылки, лучше всего, если он может быть константным.

30. [Рекомендация] Старайтесь не использовать физическое удаление (прямое удаление, если хотите удалить, сделайте резервную копию заранее), а используйте логическое удаление, для логического удаления используйте поле delete_flag, тип tinyint, 0 означает нет удалено, 1 означает уже удалено

31. [Обязательно] При написании логики запроса подкачки в коде, если счетчик равен 0, он должен вернуться напрямую, чтобы избежать выполнения последующего оператора подкачки.

32. [Обязательно] Программам необходимо использовать разные учетные записи для подключения к разным базам данных.

33. [Рекомендация] Используйте ISNULL(), чтобы определить, является ли это значение NULL.

9. Кодекс поведения

1. [Обязательно] Запрещается использовать учетную запись в файле конфигурации приложения для ручного доступа к онлайн-базе.

2. [Обязательно] Лицам, не являющимся администраторами баз данных, запрещено выполнять запись в онлайн-базу данных. Для изменения онлайн-данных необходимо отправить и выполнить рабочее задание администратором базы данных. Представленный оператор SQL должен быть проверен.

3. [Обязательно] Онлайн-стресс-тестирование базы данных запрещено.

4. [Обязательно] Запрещено прямое подключение к онлайн-базе данных из среды тестирования и разработки.

5. [Обязательно] Запрещается выполнять операции фоновой статистики с основной базой данных, чтобы не влиять на бизнес, а фоновую статистику можно выполнять с автономной подчиненной базой данных.

10. Спецификация процесса

1. [Обязательно] Все операции создания таблицы должны быть заранее уведомлены о запросе sql, участвующем в таблице.

2. [Обязательно] При создании всех таблиц необходимо определить, какие индексы следует строить, прежде чем таблицу можно будет построить онлайн.

3. [Обязательно] При всех изменениях структуры таблицы и операциях добавления индексов необходимо отправлять sql-запрос, связанный с таблицей, для информирования администратора базы данных и другого соответствующего персонала.

4. [Обязательно] Прежде чем создавать новую таблицу и добавлять поля, необходимо отправить электронное письмо как минимум за 3 дня, чтобы дать dbas время для оценки, оптимизации и проверки.

5. [Обязательно] Пакетный импорт и экспорт данных требует, чтобы администратор базы данных просматривал и наблюдал за сервисом во время выполнения.

6. [Обязательно] Запретить существование учетных записей приложений с суперпривилегиями.

7. [Обязательно] Администратор базы данных должен быть уведомлен заранее для оценки трафика для рекламных мероприятий или запуска новых функций.

8. [Обязательно] Не обновляйте и не запрашивайте базу данных пакетно в часы пик.

9. [Обязательно] Изоляция онлайн- и офлайн-среды (программам разработки и тестирования запрещен доступ к онлайн-базам данных)

10. [Обязательно] При изменении структуры таблицы большой таблицы, например, изменении атрибутов полей, таблица будет заблокирована и вызовет задержки в работе базы данных, тем самым влияя на онлайн-бизнес. изменение позволяет избежать блокировки таблиц и сокращает время задержки выполнения.

11. [Обязательно] Изменения в основной бизнес-базе данных должны быть выполнены рано утром.

12. [Рекомендация] Включите функцию журнала аудита аудита в сводной библиотеке, чтобы ее можно было отследить в случае возникновения проблемы.

13. [Обязательно] При предоставлении разрешения деловому лицу пароль должен быть зашифрован MD5, не менее 16 символов. Если нет особых требований к разрешениям, все они являются разрешениями на выборочный запрос и ограничены на уровне таблицы базы данных.

14. [Рекомендация] Если данные утеряны из-за неправильных действий человека со стороны бизнес-отдела и данные необходимо восстановить, как можно скорее сообщите об этом администратору базы данных и предоставьте важные подсказки, такие как точное время и отчеты о неправильных операциях.

15. [Обязательно] Данные пакетного обновления, такие как операции обновления и удаления, требуют, чтобы администратор базы данных просматривал и наблюдал за сервисом во время выполнения.

16. [Обязательно] При наличии ошибки в программе бизнес-подразделения и других проблем, влияющих на работу службы базы данных, просьба своевременно сообщить об этом администратору базы данных для поддержания стабильности службы.

17. [Обязательно] Операция изменения онлайн-базы данных должна предусматривать соответствующий план отката.

18. [Обязательно] Пакетная очистка данных должна рассматриваться совместно разработчиком и администратором базы данных. Она должна выполняться в часы пик, а статус сервиса должен наблюдаться в процессе выполнения.

19. [Обязательно] При удалении и изменении записей необходимо сначала выбрать, а затем выполнить оператор обновления после подтверждения его правильности, чтобы избежать случайного удаления.

Автор｜Сюе

Нажмите, чтобы попробовать облачные продукты бесплатно прямо сейчас и начать практическое путешествие в облаке!

Исходная ссылка

Эта статья является оригинальным контентом Alibaba Cloud и не может быть воспроизведена без разрешения.