Оригинал: Miss Sister Taste (идентификатор публичной учетной записи WeChat: xjjdog), добро пожаловать, пожалуйста, сохраните источник для перепечатки.
Вечером меня позвали в большой кабинет, где директор заваривал чай. В скороварке кипит чайник с длинным ртом, с затяжным паром. Когда ведущий поднял руку, вылился светло-желтый чай, налил чай вверх дном и вытекло две чашки чая.
«Пить чай?» Ведущий пододвинул мне чашку и сделал глоток. После долгого молчания я повернул монитор в свою сторону: "Недавно в таблице БД появилось кое-что интересное, заходите и смотрите".
Я посмотрел на свою голову, и мое сердце было наполовину холодным.
Спустя пять лет снова вижу тебя в проекте哥哥стол и妹妹Поля, действительно заставляют меня нервничать. Так называемые часы Brother называютсяggтаблица базы данных, что означает公共; Так называемое сестринское поле носит названиеmmПодраздел таблицы , значение密码. По сравнению с дерьмовой горой эти названия более изобретательны и являются примерами неровностей.
Такая волшебная штука появлялась не раз, и любой руководитель не сможет усидеть на месте. Жаль, что встреча за встречей, посвященная обсуждению некоего постановления о запрете SQL, наконец открыла дверь для удобства, и прошлые нормативные обязательства были забыты.
Стандарт именования баз данных является самым базовым стандартом, и даже это не выполняется должным образом, что доказывает, что в работе по надзору действительно есть недостатки. Я быстро достал свой мобильный телефон, перешел к статье xjjdog, и планировал сообщить руководителю моменты, на которые следует обратить внимание в базе данных.
Также отчитаться перед всеми.
Я разделил спецификацию на шесть частей: унифицированная спецификация, спецификация индекса, спецификация SQL, спецификация именования, спецификация безопасности и небольшая производительность.
Пожалуйста, послушай меня медленно.
1. Единая норма
Во-первых, давайте подойдем к некоторым общим спецификациям. Здесь много значений опыта.Если аппаратное обеспечение хоста, на котором расположена ваша база данных, не очень хорошее, вы можете рассмотреть возможность снижения стандарта.
Механизм хранения:Пожалуйста, используйте механизм хранения innodb единообразно, а специальный механизм базы данных должен пройти проверку администратора баз данных.
набор символов: Унифицированное использование набора символов utf8. Это должно быть унифицировано с приложением, сервером, таблицами базы данных, полями и т. д. Примечание: в MySQLutf8mb4Набор символов — настоящий utf8, используйте его.
Сфера: не храните в MySQL большие объекты, такие как изображения, музыку и т. д., не используйте MySQL для операций ГИС и полнотекстового поиска, не используйте хранимые процедуры, триггеры, функции и внешние ключи, чтобы не повредить производительности и масштабируемость базы данных.
Использовать верхний предел:
- Для каждого экземпляра MySQL количество баз данных не должно превышать 50;
- Емкость одной базы данных не должна превышать 500 ГБ, иначе она будет разбита на базы данных;
- Количество записей в одной таблице не должно превышать 5000W, иначе она будет разбита на таблицы;
- Количество подразделов в одной таблице не должно превышать 30, иначе таблица будет разбита;
- Количество индексов в одной таблице не превышает 5, а количество полей в одном индексе не превышает 5;
- Максимальное значение поля varchar не превышает 1024. Примечание: N в VARCHAR(N) представляет собой количество символов, а не количество байтов.
2. Спецификация индекса
Индекс — это очень важная структура в базе данных, которая может ускорить извлечение данных. Но индексы занимают много места, и если в вашей таблице данных мало записей, вам не нужно создавать индексы. Например, 2000 или меньше.
Поля с низкой избирательностью (столбцы с низкой кардинальностью) не должны индексироваться. Например, некоторое состояние, тип, логическое суждение и т. д. Потому что добавлять его бесполезно.
Старайтесь, чтобы содержание указателя было как можно короче! Для более длинных подразделов используйте индекс префикса. Например:title varchar (64), вы можете создать индекс префиксаidx_title (title(16)) .
Разумно используйте крайний левый принцип индексов для объединения похожих индексов. Например, (a) (ab) (abc) три требования к индексу, нам нужно только создать индекс abc, и это нормально.
Избегайте выполнения вычислений для индексированных столбцов (это сделает индекс недействительным), напримерdata_format(created_date),substring(short_name,0,6) = 'xjjdog'.
Не работает%Префикс нечетких запросов, потому что нельзя использовать индексы, например:WHERE name LIKE '%味道'.
Вы не можете использовать сторону базы данных для операций полнотекстового поиска. Не делайте этого, даже если он поддерживает это.
Именование индекса должно соответствовать правилам:idx_Префикс указывает на нормальный индекс, в то время какuk_Префикс указывает на уникальный индекс.
3. Спецификация SQL
В каждую таблицу рекомендуется добавить следующие три поля. На самом деле, SpringBoot JPA также рекомендует добавить эти три поля. В соответствии с полем времени, в дополнение к аудиту, он также может выполнять некоторые очень хорошие операции миграции; поле версии представляет собой реализацию оптимистичной блокировки при высоком уровне параллелизма, а оператор UPDATE можно комбинировать с полем версии, чтобы избежать несоответствий, вызванных параллельным выполнением. операции.
- created: время создания записи, тип времени
- модифицировано: время модификации записи, тип времени
- версия: тег версии «оптимистической блокировки», длинный, по умолчанию 0
Большинство полей должны быть определены какnot null, и назначьте значение по умолчанию, но неdefault null, так как база данных не может индексировать нулевые значения.
Категорически следует избегать сложных операторов SQL-запросов. Мы говорим о медленных запросах. Медленные запросы будут занимать много ресурсов и блокировать потоки, поэтому вам следует простить разбиение большого SQL на несколько простых SQL для сокращения времени блокировки данных.
Кроме того, не сравнивайте поля разных типов данных, чтобы избежать потери производительности, вызванной преобразованием типа поля, которое требует от нас передачи типа параметра в операторе SQL, а тип, определенный в базе данных, одинаков.
Запрещено использоватьselect *Для вывода должны быть выбраны определенные поля для вывода. В дополнение к предотвращению потери производительности при передаче, вызванной бесполезными полями, это также может в определенной степени предотвратить утечку конфиденциальной информации.
В SQL избегают функций с неопределенными результатами, таких как now(), rand(), sysdate() и current_user().
Использование порядка методом rand() запрещено.
Оператор Insert, не используйте nsert в значениях таблицы() напрямую, но следует добавить определенные поля, иначе он не сможет адаптироваться к изменениям базы данных. При пакетной вставке одновременно может выполняться 100-200 операций, и нет необходимости устанавливать количество пакетов в десятки тысяч.
Запретите бизнес-код, не относящийся к фреймворку, вызывайте его напрямуюset sql_modeилиset tx_isolation, использованиеSELECT … FOR UPDAT, оптимистичная реализация блокировки является предпочтительной.
Многотабличных ассоциаций должно быть не более 3, и постарайтесь разбить их на простую обработку SQL.
Большинство разработчиков пишут UNION, когда это необходимо, что, как правило, приводит к выполнению сортировки для устранения дубликатов. Вы должны попытаться использовать UNION ALL вместо UNION.
Обратите внимание на некоторые улучшения оператора OR. НапримерWHERE id=1 OR id=2можно переписать какWHERE id IN(1,2). В разных полях ИЛИ можно переписать какUNION ALL.
4. Соглашения об именах
Не используйте верблюжий регистр для именования таблиц и полей базы данных. Например, вы не можете позвонитьsaleOrder, который следует назватьsale_order. Поскольку большинство баз данных не чувствительны к регистру, имена с подчеркиванием безопаснее.
В этих именах могут использоваться только английские строчные буквы, цифры и знаки подчеркивания, а длина не превышает 17 символов.
Имя должно иметь точное значение. Как и в спецификации кода, бессмысленные строки, такие как a, b и т. д., не допускаются. Китайские сокращения пиньинь и смешанное использование китайского и английского языков не допускаются.
Таблица Brother и родственные поля строго запрещены.
5. Сейф Сейф Сейф
(1) Изоляция сервера Если в вашей компании несколько сред, таких как среда разработки, среда тестирования и т. д., вы должны хорошо поработать над изоляцией. Например, прямая разработка и тестирование в онлайн-среде запрещены, а стресс-тестирование базы данных запрещено в онлайн-режиме. Это очень важно, чтобы избежать ненужного беспорядка данных. Если позволяют условия, вы даже можете сделать физическую изоляцию и использовать разные IP-сегменты для различения. Есть много программистов, у которых нет длинных мозгов, никогда не знаешь, к какой базе данных среды они подключены.
(2) Разрешения учетной записи Никогда не делайте учетную запись root удаленно подключаемой в рабочей среде. Для разных приложений должны быть выделены разные базы данных и созданы отдельные учетные записи.
По умолчанию учетная запись включает разрешения на выбор/вставку/обновление/удаление/выполнение. Create не может быть выпущен, и это практически исключает возможность для программистов удалить библиотеку и сбежать.
Для приложений с высоким уровнем безопасности должны быть выделены учетные записи для чтения и записи. Учетная запись чтения удаляет различные разрешения на обновление и может выполнять только некоторые запросы SQL. Что касается именования учетной записи, вы можете добавить_wили_rсуффикс, указывающий на их намерение.
Входящие параметры SQL (числа, символы и смешанное использование) должны проверяться на достоверность, чтобы предотвратить внедрение SQL. Предприятия должны заранее подготовить рискованные операторы SQL, провести централизованный аудит и нести ответственность за последствия.
6. Небольшой футляр для производительности
Для автоматически увеличивающихся полей используйте unsigned (без знака) int или bigint. Предпочтительнее использовать меньшие типы данных, например:
- Числа используют типы tinyint, smallint, mediumint, int, bigint;
- Дата с датой, тип даты и времени;
- Время использует метку времени, тип int;
- Не используйте char, varchar для хранения даты и времени;
- Используйте меньший тип данных, если вы можете использовать tinyint, вам не нужен smallint, если вы можете использовать отметку времени, вам не нужен тип datetime;
Нельзя использовать поля типа Tinyblob, mediumblob, blob и longblob.Для таблиц с большими типами полей следует рассмотреть возможность отдельного разбиения.
Базы данных OLTP должны избегать крупных транзакций и операций на стороне базы данных, а также рассмотреть возможность использования NoSQL или платформ для обработки больших данных.
End
Видно, что некоторые запрещенные в нашей спецификации вещи в итоге действительно используются. Например, таблица разделов, большое поле для хранения, работа с ГИС. Но это не противоречит норме.
Норма лишь определяет некоторые общие запреты на операции, которые могут привести к серьезным последствиям, а затем передает рискованные вещи профессиональным людям для оценки и контроля шкалы баллов риска.
Спецификации заданы, и они должны быть реализованы. Будь то ручной просмотр или обнаружение инструмента. Таким образом, система сможет нормально развиваться, программисты смогут перестать работать сверхурочно, а руководители смогут управлять Porsche.
В это время я закончил отчет и посмотрел на лидера. Его голова покоилась на спинке кожаного сиденья, и он заснул. Я осторожно снял пальто и надел его на него, затем взял свою чашку и выпил ее с гудонгом. Хотя чай был холодным, мягкий аромат остался во рту.
Об авторе:Мисс сестра вкус(xjjdog), публичная учетная запись, которая не позволяет программистам идти в обход. Сосредоточьтесь на инфраструктуре и Linux. Десять лет архитектуры, десятки миллиардов ежедневного трафика, обсуждение с вами мира высокой параллелизма, дающие вам другой вкус. Мой личный WeChat xjjdog0, добро пожаловать в друзья для дальнейшего общения.