Автор оригинала: David Wong.
В этой статье обобщен опыт и здравый смысл в разработке PHP + mysql . Чтобы поделиться с вами для вашей справки, следующим образом:
1, Базовая спецификация
(1) Попробуйте использовать механизм хранения InnoDB
Поддержка транзакций, блокировка уровня строк, улучшенная производительность параллелизма, страница кэша процессора и памяти должным образом оптимизирована, а использование ресурсов выше
(2) Требуется набор символов Utf8
Нет необходимости перекодировать, нет риска беспорядочного кода
(3) Таблица данных и поле данных должны быть добавлены с китайскими примечаниями
Кто знает, что это за поле R1, R2, R3 через n лет
(4) Старайтесь не использовать хранимые процедуры, представления, триггеры, события
Для интернет-бизнеса с высоким уровнем параллелизма и большими данными идея проектирования архитектуры состоит в том, чтобы “освободить центральный процессор базы данных и перенести вычисления на уровень обслуживания”. В случае большого параллелизма эти функции, скорее всего, приведут базу данных к смерти, а бизнес-логика на уровне обслуживания обладает лучшей расширяемостью, что позволяет легко реализовать “машину сложения и производительность”. База данных хороша в хранении и индексировании, а вычислительные ресурсы процессора максимально перемещены на верхний уровень
(5) Не храните большие файлы или фотографии
Не позволяйте базе данных делать то, в чем она не очень хороша. Большие файлы и фотографии хранятся в файловой системе (с помощью службы загрузки), а URI хранится в базе данных
2. Соглашения об именовании
((6) Название библиотеки, название таблицы, название поля: нижний регистр, стиль подчеркивания, не более 32 символов, должно быть видно значение имени, без смешения пиньинь и английского допускается
(7) Краткое и понятное имя таблицы, не уникальное имя индекса idx_ XXX, уникальное имя индекса uniq_ XXX
3, Технические характеристики конструкции таблицы
(8) Количество таблиц с одним экземпляром должно быть менее 500
(9) Количество отдельных столбцов таблицы должно быть менее 30
(10) Таблица должна иметь первичный ключ, например, первичный ключ с автоматическим увеличением
a) С увеличением первичного ключа запись данных с помощью datarow может повысить производительность вставки, избежать разделения страниц, уменьшить фрагментацию таблиц и улучшить использование пространства и памяти
b) Чтобы выбрать более короткий тип данных для первичного ключа, обычные индексы движка InnoDB сохранят значение первичного ключа. Более короткие типы данных могут эффективно сократить дисковое пространство индекса и повысить эффективность кэширования индекса. C) удалять таблицы без первичного ключа. В режиме строки первичная и вторичная архитектуры приведут к зависанию резервной базы данных
(11) Не используйте внешние ключи. Если существуют ограничения целостности внешнего ключа, требуется контроль приложений
Внешний ключ вызовет связь между таблицами. Операции обновления и удаления будут включать связанные таблицы, что значительно повлияет на производительность SQL и даже приведет к взаимоблокировке. В случае высокого параллелизма легко снизить производительность базы данных. В случае больших объемов данных и бизнес-сценария с высоким уровнем параллелизма производительность базы данных имеет приоритет
4, Спецификация конструкции поля
(12) Поле должно быть определено как not null и иметь значение по умолчанию должны быть предоставлены
a) Столбец Null делает сравнение индекса/статистики индекса/значений более сложным и сложным для оптимизации для MySQL b) В этом типе MySQL требуется специальная обработка для увеличения сложности записей обработки базы данных. При тех же условиях, когда в таблице много пустых полей, производительность обработки базы данных будет значительно снижена c) Нулевому значению требуется больше места для хранения. Независимо от того, является ли это таблицей или нулевым столбцом в каждой строке индекса, для определения d требуется дополнительное пространство) При работе с null можно использовать только значение null или не значение null вместо символов операции =, in, < и <,! =, не входит. Например: где. Если имеется запись со значением имени null, результат запроса не будет содержать запись со значением имени null
(13) Типы текста и больших двоичных объектов запрещены
Больше места на диске и в памяти будет потрачено впустую, а ненужные запросы на большие поля устранят “горячие” данные, что приведет к резкому снижению скорости обращения к памяти и повлияет на производительность базы данных
(14) Избегайте десятичных валют
Используйте целочисленное хранилище, десятичное легко привести к деньгам не до
(15) Номер телефона должен быть сохранен с помощью varchar (20)
- a) Это включает в себя код города или код страны, а также + – ()
- б) Будут ли номера мобильных телефонов выполнять математику?
- c) Varchar может поддерживать нечеткие запросы, такие как “138%”
(16) Перечисление запрещено, и вместо него можно использовать tinyint
- a) Добавьте новое значение перечисления для операции DDL
- b) Внутреннее фактическое хранилище перечисления является целочисленным. Как вы думаете, то, что вы определяете, является строкой?
5, Спецификация дизайна индекса
(17) Предлагается контролировать индекс одной таблицы в течение 5
(18) Количество полей с одним индексом не должно превышать 5
При наличии более 5 полей функция фильтрации данных больше не действует
(19) Запрещается создавать индексы по атрибутам с частыми обновлениями и низкая дискриминация
- a) Обновление изменит дерево B+, а частое обновление полей для создания индексов значительно снизит производительность базы данных
- б) “Пол” – это атрибут с небольшой дифференциацией, поэтому создавать индекс бессмысленно, и он не может эффективно фильтровать данные. Его производительность аналогична производительности сканирования полной таблицы
(20) Для построения составного индекса необходимо сначала выделить высокодифференцированное поле
Может более эффективно фильтровать данные
6, Спецификация использования SQL
(21) запрещено использовать select *, получаются только необходимые поля, и требуется атрибут столбца описания для отображения
- а) Чтение ненужных столбцов увеличит процессор, ввод-вывод и чистое потребление
- б) Не может эффективно использовать индекс наложения
- c) Использование select * легко вызвать ошибку программы после добавления или удаления полей
(22) вставить в t запрещенные значения_ XXX (xxx), должно отображаться свойство столбца, указанное для вставки
Ошибка программы легко появляется после добавления или удаления полей
(23) запретить использование неявного преобразования атрибутов
SELECT uid FROM t_user WHERE phone=13812345678
Это приведет к полному сканированию таблицы без попадания в телефонный индекс
(24) избегайте использования функций или выражений в свойствах условий where
SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02-15'
Правильный способ написания полного сканирования таблицы-это:
SELECT uid FROM t_user WHERE day>= unix_timestamp('2017-02-15 00:00:00')
(25) избегайте отрицательного запроса и запрещайте нечеткий запрос в начале%
а) Отрицательные условия запроса: нет,! =, < >,! <,! >, не в, не нравится и т. Д., Что приведет к полному сканированию таблицы b) Нечеткий запрос в начале% приведет к полному сканированию таблицы
(26) избегайте использования запроса объединения и подзапроса в больших таблицах
Это приведет к созданию временных таблиц, потребит больше памяти и процессора и значительно повлияет на производительность базы данных
(27) избегайте использования или условия и попробуйте изменить его на в запросе
Запрос or старой версии MySQL не может попасть в индекс. Даже если он может попасть в индекс, базе данных необходимо потратить больше ресурсов процессора, чтобы помочь реализовать оптимизацию запросов
(28) приложение должно перехватывать исключения SQL и обрабатывать их соответствующим образом
Для получения дополнительной информации о PHP читатели, интересующиеся PHP, могут ознакомиться с нашими специальными разделами: Введение в работу с базой данных PHP + MySQL, краткое изложение навыков программирования баз данных PHP + mysqli, введение в объектно-ориентированное программирование PHP, набор навыков работы с массивами PHP, Краткое изложение использования строк PHP и общие навыки работы с базами данных PHP резюме
Я надеюсь, что эта статья будет полезна для программирования на PHP.
Оригинал: “https://developpaper.com/summary-of-experience-and-common-sense-in-php-mysql-development/”