[Stepashka]

• В данной теме собраны часто задаваемые вопросы по MySQL и информация о том как с ним обращаться для получения наилучшей производительности.
• Тема будет постоянно дополняться и пополняться информацией.
• В данной теме не описывается скриптинг с применением мускула и не решаются ваши проблемы с кодом, она создана для решения вопросов касающихся непосредственно самого MySQL.

MySQL, мощное средство для хранения и получения большого количества данных. Заметьте не обработки, а именно хранения и получения! Да, на нем можно обрабатывать данные, но пользоваться этим нужно только для получения набора данных из имеющихся.
Если вы надеетесь что MySQL решит все ваши проблемы со скоростью обращения, записи или чтения данных, не обольщайтесь, для получения максимальной производительности не достаточно перенести ваши файлы в базу, далее БД, нужно ещё и правильно спроектировать эту БД. Данная тема поможет вам избежать частых ошибок на начальном этапе перехода на MySQL.

Итак поехали:

Кодировка таблиц

utf8_general_ci - должно отскакивать от зубов, ни какая другая. Мультибайтовая кодировка используемая в UNIX подобных системах. Позволяет избегать проблем с хранением специализированных символов и любого языка.

Советы:

• Необязательно указывать кодировку для каждого поля, достаточно выбрать её по умолчанию при создании БД. Она сама будет присваиваться для всех строковых полей и таблиц.

Имена таблиц и столбцов

Общее:

• Называйте все полными именами.
• Не используйте префиксы типа p..., h..., b....
• Не используйте разный регистр букв.
• Используйте цифры только в крайнем случае.
• Для разделения слов используйте "_" (землю).
• Избегайте зарезервированных/системных слов, всегда можно найти слово синоним!

Таблицы:
Называйте таблицы в единственном числе, английскими названиями, например house, player, place. Это упростит понимание того что это за таблица и сделает работу с ней более интуитивной. И упростит интеграцию с сайтом в будущем, если планируется.

Ключи

Общее:

• Не пренебрегайте созданием ключей, это основное средство которое ускорит работу вашей БД.
• Если это записи данных у них всегда должен быть уникальный ключ - идентификатор! По нему должны производится обновления данных. Обычно это просто INT поле с ключём AUTO_INCREMENT. Ни когда не пытайтесь исправлять или перезаписывать данное поле самостоятельно, это должна делать только ваша БД без вашего участия.
• Чем больше ключей в вашей таблице, тем быстрее вы будете получать данные. Это не значит что нужно создавать ключи по каждому полю. При подобном подходе вы получите только разрастающийся файл индексов, но не получите прироста скорости.

Как же создавать ключи:
Все просто, с умом. Например все мы знаем что в SA-MP не могут играть два человека с одинаковыми именами, при чем регистр не учитывается, поэтому для поля с никами игроков вы всегда смело можете создавать уникальный ключ. Для остальных ключей нужно просто посмотреть по каким критериям происходит выборка данных: например дома мы часто получаем по полю владельца, значит навесив на это поле ключ мы сможем быстро находить пустые дома, или мы можем указать у домов город в котором он находится, тогда ключ по этому полю позволит с легкостью находить дома в конкретном городе.
Так же не забывайте что в ключах можно комбинировать несколько полей. Но помните, что чем больше вариантов скомбинированных данных, тем быстрее будет разрастаться таблица индексов.

Дата и время

Общее:

• Никогда не используйте для записи в БД или сравнения функции NOW(), UNIX_TIMESTAMP() или им подобные! Время на сервере может не соответствовать времени БД. Всегда используйте время на сервере.
• Заранее определитесь в каком формате вам проще хранить дату и время.
• БД дает мощнейшие средства для конвертирования даты и времени в любой формат, не пренебрегайте ими.

P.S. Если вас интересует что-то ещё или есть что дополнить, пишите в комментариях, дополню информацию.
__________________________________________________ _________________________________

F.A.Q.

• Не корректно записываются/читаются русские символы.
• Что такое лэйблы и как использовать as.

[Stepashka]

Code:

 SET NAMES cp1251;
 SET SESSION character_set_server='utf8';

Не забываем что всеми любимый phpmyadmin по умолчанию работает не на utf8, не забываем его перенастроить.

[Stepashka]

Иногда происходит необходимость произвести сложный запрос, с обращением в две или более таблиц, или упростить имя столбца в результирующих данных, как же быть?!
Для этого в SQL есть лэйблы, призванные упростить понимание написанного.
На примерах это будет более очевидно:

Code:

SELECT
	players.username, house.pos_x, house.pos_y, house.pos_z
FROM
	players, house
WHERE
	players.banned = 0
	AND house.owner = players.username

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

Code:

SELECT
	p.username, h.pos_x, h.pos_y, h.pos_z
FROM
--	players as p, house as h
	players p, house h
WHERE
	p.banned = 0
	AND h.owner = p.username

Стало гораздо приятней.
Обращаю ваше внимание на вариант с написанием as, данное слово дословно обозначает "называть как", т.е. в нашем примере таблицу players называть как p. В 5 версии MySQL данным словом можно пренебрегать, что и было сделано.
Выполнив данный запрос мы обнаружим что наши столбцы называются так как мы написали:

Code:

p.username, h.pos_x, h.pos_y, h.pos_z

Улучшим и это:

Code:

SELECT
	p.username as username,
	h.pos_x as x,
	h.pos_y as y,
	h.pos_z as z
FROM
	players p, house h
WHERE
	p.banned = 0
	AND h.owner = p.username

Теперь в результате мы получим столбцы с именами:

Code:

username, x, y, z

В данном случае пренебрегать словом as нельзя.

Также по лэйблам, тем что переназначают имена столбцов, можно производить сортировку, группировку и поствыборку.

[hub4]

до лейблов все тоже вполне неплохо читалось) имхо только уменьшение длины.
ты лучше другое обьясни. разве для многотабличных запросов не JOIN надо пользовать?
каким образом в твоем первом примере сервер определяет по каким параметрам в какой таблице искать?

[Stepashka]

Quote:

Originally Posted by hub4 до лейблов все тоже вполне неплохо читалось) имхо только уменьшение длины. ты лучше другое обьясни. разве для многотабличных запросов не JOIN надо пользовать? каким образом в твоем первом примере сервер определяет по каким параметрам в какой таблице искать?

А ты умеешь правильно пользоваться JOIN? Лучше их избегать.
По сути это проблема MySQL, а вообще FROM не указывает что выборка должна производится из этих таблиц, оно указывает какие таблицы будут использоваться в запросе, а вот WHERE уже формирует запрос и по его условиям сервер производит выборку, в данном случае он сперва выберет пользователей, а потом для каждого пользователя сделает подзапрос во вторую таблицу и сопоставит данные.

[Urukhay]

Хотелось бы более конкретного описания с примерами создание ключей.

[Nazarik]

Как лучше всего хранить данные, например для лицензии. (a,b,c,d)
В 1 поле ? "0|0|0|0"
или под каждую лицензию свое поле ?

[Splav]

Quote:

Originally Posted by Nazarik Как лучше всего хранить данные, например для лицензии. (a,b,c,d) В 1 поле ? "0|0|0|0" или под каждую лицензию свое поле ?

Как удобнее тебе

[Stepashka]

Quote:

Originally Posted by Nazarik Как лучше всего хранить данные, например для лицензии. (a,b,c,d) В 1 поле ? "0|0|0|0" или под каждую лицензию свое поле ?

Зависит от того где это будет использоваться, если только на сервере, то выше ответили. Если ещё и на сайте, а тем более в какой-то CMS, то отдельное поле.
Не встречал ни одной CMS которая могла бы, по умолчанию, работать с бинарными полями. Да и наглядней это.

[ZiGGi]

Quote:

Originally Posted by Nazarik Как лучше всего хранить данные, например для лицензии. (a,b,c,d) В 1 поле ? "0|0|0|0" или под каждую лицензию свое поле ?

Есть нормальная форма, лучше придерживаться её: http://ru.wikipedia.org/wiki/Нормальная_форма

[Alexander_Petrov]

Инсерт не работает с лимитом

[stabker]

Помогите сформулировать запрос. Нужно достать biz.*, а так же поле users.name AS owner_name, где biz.owner_id = users.id если biz.owned (если нет, в owner_name возвращать что-то другое, либо "").

[Stepashka]

Quote:

Originally Posted by stabker Помогите сформулировать запрос. Нужно достать biz.*, а так же поле users.name AS owner_name, где biz.owner_id = users.id если biz.owned (если нет, в owner_name возвращать что-то другое, либо "").

Code:

SELECT
	*,
	IFNULL((SELECT name FROM users WHERE biz.owner_id = users.id), '') AS owner_name
FROM biz
WHERE owned

[stabker]

Quote:

Originally Posted by Stepashka Code: SELECT *, IFNULL((SELECT name FROM users WHERE biz.owner_id = users.id), '') AS owner_name FROM biz WHERE owned

Спасибо! Теперь буду знать. Только мне, скорее, нужно так:

Code:

SELECT
	*,
	IF(biz.owned, (SELECT name FROM users WHERE biz.owner_id = users.id), "") AS owner_name
FROM biz

[Stepashka]

Quote:

Originally Posted by stabker Спасибо! Теперь буду знать. Только мне, скорее, нужно так: Code: SELECT *, IF(biz.owned, (SELECT name FROM users WHERE biz.owner_id = users.id), "") AS owner_name FROM biz

это разные запросы.
В первом случае получит все дома у которых есть владельцы, а потом дополнит полученные данные именами владельцев или пустотами.
Во втором, получить все дома и потом дополнит их все именами владельцев или пустотами.

[stabker]

Quote:

Originally Posted by Stepashka это разные запросы. В первом случае получит все дома у которых есть владельцы, а потом дополнит полученные данные именами владельцев или пустотами. Во втором, получить все дома и потом дополнит их все именами владельцев или пустотами.

Я понимаю, поэтому мне как раз второй вариант и нужен.

[Urukhay]

Quote:

Originally Posted by Stepashka Code: SELECT *, IFNULL((SELECT name FROM users WHERE biz.owner_id = users.id), '') AS owner_name FROM biz WHERE owned

А зачем использовать 'AS owner_name' в Вашем запросе?

[Stepashka]

Quote:

Originally Posted by Urukhay А зачем использовать 'AS owner_name' в Вашем запросе?

что бы в получившихся данных столбец имел имя owner_name, если этого не делать имя будет IFNULL((SELECT name FROM users WHERE biz.owner_id = users.id), '').
Согласен что для sa-mp это не принципиально так как столбцы вытаскиваются порядковым номером.

[Urukhay]

После проделывания опытов с табличкой, в которой был столбец k_id (AI + уникальный) и столбец s_id (Primary Key), я решил пересоздать столбец k_id, тобишь я удалял строки, и у меня оставались строки с k_id 1,5,6. Ну а мне надо чтобы все были по порядку с единицы. Ну я удалил столбец с АI k_id, ибо его изменять нельзя.. А создать снова не получается, пишет "multiple primary key defined". А он не был первичным.

[Stepashka]

Quote:

Originally Posted by Urukhay После проделывания опытов с табличкой, в которой был столбец k_id (AI + уникальный) и столбец s_id (Primary Key), я решил пересоздать столбец k_id, тобишь я удалял строки, и у меня оставались строки с k_id 1,5,6. Ну а мне надо чтобы все были по порядку с единицы. Ну я удалил столбец с АI k_id, ибо его изменять нельзя.. А создать снова не получается, пишет "multiple primary key defined". А он не был первичным.

AI поля по умолчанию Primary Key.
И в который раз повторяю: НИ КОГДА НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ НЕ ТРОГАЙТЕ И НЕ ИЗМЕНЯЙТЕ AI ПОЛЯ!