MySQL скорость: help

привет
есть проблема...

PHP скрипт: 1 коннект и 5 запросов к MySQL 4.1.21 базе (2 Select и 3 Insert);
примерно 10к запросов в час на этот скрипт;
как результат 100% загрузка проца и разростание свопа до безобразия, иногда падение базы;

сервер P4 3.0, 1Gb, SCSI
с базой соединяюсь через mysql_connect

вот скажите, в чем глюк?
что нужно оптимизировать?

Ну имхо без структуры таблиц, кол-ва записей и алгоритмов запросов. Наверно мало что можно сказать.

Структуру базы , запросы в студию ,конфиг мускуля, ясновидящие все в отпуске....

переписал скрипт... сча тестирую...
если опять такая ерунда... тогда выложу все в студию...

Оффтопик: мама, чому я не программер

Специально посмотрел -- 88.62 запросов в секунду на одном из моих серверов. Так что что-то у тебя с запросами... Сколько записей в таблице?

несколько сотен тыс в сутки добавляется

Select по 2м полям VARCHAR(255)
походу именно этот элемент грузил сильно...
отключил временно > нагрузка ноль )

индекс по ним Fulltext ставить? или как? если нужно полно совпадание фразы...

Insert Не надо ведь никак оптимизировать? или я не прав?

keenza писал:

несколько сотен тыс в сутки добавляется

програмера решению которого в базу добавляется сотни тысяч записей в сутки - можно смело расстреливать.

keenza писал:

Select по 2м полям VARCHAR(255)

Селект по стрингам самый сложный для мускула.
1. сделай analize он тебе посоветует в соотвествии с данными - какой тип поля поставить.
2. индекс по ним Fulltext ставить - лично я не советую. Хотя это поможет. Лучше переделать структуру при которой у тебя есть необходимость делать такой запрос.

keenza писал:

Insert Не надо ведь никак оптимизировать? или я не прав?

Всегда есть, что оптимизировать. Например если инсерт не критичен можно рассмотреть Delayed Insert

keenza писал:

или как? если нужно полно совпадание фразы...

Надеюсь ты не делаешь: SELECT FROM table WHERE field LIKE '%myquery%' ???

Crusader писал:

програмера решению которого в базу добавляется сотни тысяч записей в сутки - можно смело расстреливать.

сколько трафа столько и записей, не больше не меньше..
да и не программер я ), а отдать такой скрипт в руки программера мне не хочется , да и цену за него мне заломили больше 5к

Crusader писал:

Селект по стрингам самый сложный для мускула. 1. сделай analize он тебе посоветует в соотвествии с данными - какой тип поля поставить. 2. индекс по ним Fulltext ставить - лично я не советую. Хотя это поможет. Лучше переделать структуру при которой у тебя есть необходимость делать такой запрос.

без селекта по стринговым полям никак, вот и мучаюсь

Crusader писал:

Всегда есть, что оптимизировать. Например если инсерт не критичен можно рассмотреть Delayed Insert

ок, попробуем

Crusader писал:

Надеюсь ты не делаешь: SELECT FROM table WHERE field LIKE '%myquery%' ???

нет, делаю через =

Вопрос
в одно поле записыватеся IP, тип данных: varchar(15) индекс FULLTEXT
есть смысл менять на какой другой тип?

спасибо, за советы! жду еще

keenza писал:

Вопрос в одно поле записыватеся IP, тип данных: varchar(15) индекс FULLTEXT есть смысл менять на какой другой тип? спасибо, за советы! жду еще

Блина нафига varchar!!!
Быстро избавляйся, юзай тип double, а IP в скрипте переводи функцией ip2long , обратное преобразование с помощью функции long2ip
Varchar это всегда ЗЛО!

да, ip хранить в варчар низя.

keenza писал:

сколько трафа столько и записей, не больше не меньше..

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

Crusader писал:

програмера решению которого в базу добавляется сотни тысяч записей в сутки - можно смело расстреливать.

+1

1)varchar в топку.

2)insert батчем через FILE.

3)Афтор, ты по-русски понимать? Без структуры базы и запросов тебе нечем не помогут коих ты досих пор не продемонстрировал.

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

Цитата:

сколько трафа столько и записей, не больше не меньше..

почему бы не обрабатывать логи апача?

спасибо за дельные советы!!
реально некоторые помогли

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

но все равно спасибо ребята
хоть не на 100%, но кнопка заработала

Full text, если я не ошибаюсь, юзается только при full text search, а тебе до него далеко. Создай обычный двойной индекс по этим полям.

proc3nt писал:

Блина нафига varchar!!! Быстро избавляйся, юзай тип double, а IP в скрипте переводи функцией ip2long , обратное преобразование с помощью функции long2ip Varchar это всегда ЗЛО!

Код:

string long2ip ( int proper_address ) int ip2long ( string ip_address )

Вопрос:
я не понял зачем double? ip2long Integer возвращает

Цитата:

Full text, если я не ошибаюсь, юзается только при full text search, а тебе до него далеко. Создай обычный двойной индекс по этим полям.

у меня запрос:

Код:

// string1 VARCHAR(255) // string2 VARCHAR(255) SELECT string1, string2 FROM table WHERE string1 = 'bla-bla-bla' and string2 = 'bla2-bla2-bla2';

нужно именно полное совпадение строк...
Вопрос-2:
какой все таки индекс использовать?

этот селект грузит сервак больше всего...
на инсертах нагрузки нет

Full text тут вообще не при чем в таком запросе. Делай двойной индекс, говорю:

ALTER TABLE table ADD INDEX idx1 (string1,string2)

и дропни свой фул текстю он без надобности, а сервак грузит на инсертах и апдейтах.

И вот еще что. Если ты айпи всетаки решил в варчар хранить (извращенец ) то нах тебе 255 длина? У айпи макс длинна: "ххх.ххх.ххх.ххх" = 15 символов. Делай varchar(15)

для VARCHAR(), если оно не BINARY - это абсолютно по барабану

dm писал:

для VARCHAR(), если оно не BINARY - это абсолютно по барабану

Для варчар может и да. А вот для размера и производительности таблицы и индекса - не совсем.

Pentarh писал:

Для варчар может и да. А вот для размера и производительности таблицы и индекса - не совсем.

не, я именно размер и имел ввиду
чтобы не спорить - нашел :
11.4.1 The `CHAR' and `VARCHAR' Types
-------------------------------------
...`VARCHAR' values are stored using only as many
characters as are needed, plus one byte to record the length (two bytes
for columns that are declared with a length longer than 255).

больше 16 байтов не займет, индексы отсюда же пляшут
просто максимальный размер, после которого режется - 15 или 255 без разницы

Ну хорошо. Зри в корень. Есть у тебя строка с полем варчар 255. Туда ты записал 15 символов. Теперь ты делаешь апдейт и записываешь туда 200 символов.

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

На самом деле, мускуль резервирует для этого поля в файле 255 байт в любом случае. И при апдейте ничего не вырезает.

Получается, если реальная длина не превышает 15 байт, то имеем нехуевый overhead, учитывая что туда пишутся сотни тысяч записей в сутки.

Цитата:

На самом деле, мускуль резервирует для этого поля в файле 255 байт в любом случае.

С чего ты взял ? Резервирует вроде 2 (или 4) байта, а там сколько ты будешь использовать уже. Это char() резервирует сразу заявленное число. Иначе смысла от варчара нет.

да не надо по "моему варианту" идти, там от меня ничего не зависит
надо доки к мускулю читать просто-напросто..
ну стыдно программеру такое не знать

`VARCHAR' and the `BLOB' and `TEXT' types are variable-length types.
For each, the storage requirements depend on the actual length of column
values (represented by L in the preceding table), rather than on the
type's maximum possible size. For example, a `VARCHAR(10)' column can
hold a string with a maximum length of 10. The actual storage required
is the length of the string (L), plus one byte to record the length of
the string. For the string `'abcd'', L is 4 and the storage requirement
is five bytes.

погоди, может я просто тебя неправильно понял. Ты хочешь сказать что вот эта вот цифра 255 в определении поля varchar вообще ничего не значит?

Конкретнее вопрос. По твоему, не имеет значения, хранить ли айпи в varchar255 или varchar15?

Pentarh писал:

погоди, может я просто тебя неправильно понял. Ты хочешь сказать что вот эта вот цифра 255 в определении поля varchar вообще ничего не значит?

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

Pentarh писал:

Конкретнее вопрос. По твоему, не имеет значения, хранить ли айпи в varchar255 или varchar15?

совершенно верно, никакой разницы
ни для размера базы, ни для индексов - в любом случае 16 байт максимум

каюсь, сам я делаю BINARY VARCHAR(15) для IP
15 - чисто психологически
VARCHAR - потому что именно текстовый поиск нужен почти всегда
BINARY - без case conversion и без учета кодировок, ни к чему тут