|
|
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
Подскажите как можно оптимизировать таблицу логинов пользователей, она же используется для поиска пользователей по критериям: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Есть стандартные запросы по таблице: 1. Проверка валидности логина и пароля Код: plaintext 2. Обновление количества сообщений (происходит если кто-то пишет ему сообщение или он прочитывает одно из новых сообщений) Код: plaintext 3. Обновление времени последнего логина, (происходит только если предыдущее время < на 5 минут) Код: plaintext 4. Запрос пользователей по одному из параметров, таких как gender, active, photoHave, birthDate Вторую неделю ломаю голову, как можно сделать так чтобы не тормозило при обновлении времени последнего логина, и количества сообщений... INNO DB не предлагать нет ее в mySql 3.23 :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 18:59:15 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
разбить таблицу - в одной id, login char(32), passwd char(32), logtime timestamp и какие там еще нужны поля из тех, что фиксированой длины, а в другой - id и все остальное Идея в том, что update надо делать на маленькие записи фиксированой длины - сократите все что можно, datetime - 8 байт, лучше timestamp, если других обновлений нет. Уникальный индекс так же тормозит - подумайте, нужен ли он Вам. Для быстрого поиска лучше иметь простой индекс по (login, passwd) -- Dmitry ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 19:06:43 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
есть индекс по полям login, pass ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 19:07:12 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
Dinkyразбить таблицу - в одной id, login char(32), passwd char(32), logtime timestamp и какие там еще нужны поля из тех, что фиксированой длины, а в другой - id и все остальное такой вопрос как я понимаю скорость update увеличивается при а) фиксированной длине записи б) минимизации длины записи я правильно понимаю ? может тогда лучше для logTime сделать отдельную таблицу вроде id int(10) logTime datetime вторую таблицу id int(10) login char(32) pass char(32) третью таблицу все остальное ? я прав или это наоборот скажется отрицательно на производительности ? Dinky Уникальный индекс так же тормозит - подумайте, нужен ли он Вам. Для быстрого поиска лучше иметь простой индекс по (login, passwd) ммм.. спасите а чем же уникальный индекс медленнее чем просто индекс, и насколько это правильно следить в программном коде за уникальностью записей если есть стандартный инструмент бд ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 19:22:32 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
Имхо, разделение таблицы на две (с фиксированной длиной записи и с переменной) не сильно поможет. Оно помогло бы, если бы были массивные изменения. А в данном случае независимо от длины записи надо прочитать с диска один-два блока и записать на диск те же самые один-два блока (это не считая чтения индекса). 2 MegaTron Сколько записей в таблице? Что подразумевается под торможением сейчас? каково время выполнения запроса из пункта 3? Кстати, для более быстрого выполнения пункта 4 надо создавать раздельные индексы по полям gender, active, photoHave, birthDate, а не KEY mainSearch (gender, active, photoHave) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 19:33:38 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
MegaTron такой вопрос как я понимаю скорость update увеличивается при а) фиксированной длине записи б) минимизации длины записи да, при условии, что вы ссылаетесь на запись по primary key MegaTron может тогда лучше для logTime сделать отдельную таблицу вроде id int(10) logTime datetime вторую таблицу id int(10) login char(32) pass char(32) третью таблицу все остальное ? я прав или это наоборот скажется отрицательно на производительности ? если только logTime надо часто обновлять, то достаточно его вынести в отдельную таблицу "статистики юзера", а остальное пусть живет в своей... и чего Вы не хотите сделать его в 2 раза меньше - timestamp? :) MegaTron ммм.. спасите а чем же уникальный индекс медленнее чем просто индекс, и насколько это правильно следить в программном коде за уникальностью записей если есть стандартный инструмент бд ? потому что серверу надо тратить ресурсы на проверку уникальности всякий раз при изменении/добавлении -- Dmitry ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 22:58:47 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
а explain можно посмотреть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 23:28:44 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
miksoft 2 MegaTron Сколько записей в таблице? Что подразумевается под торможением сейчас? каково время выполнения запроса из пункта 3?] В том то и дело, что таблица то небольшая SELECT * FROM users 3394 всего, Query took 0.0737 sec Торможение заключается в том что запросы вроде простой выборки всех записей Код: plaintext иногда занимают до 10-15 секунд :( Как я понимаю это происходит из-за того что в процессах всегда висит 10-50 запросов вида Код: plaintext miksoft Кстати, для более быстрого выполнения пункта 4 надо создавать раздельные индексы по полям gender, active, photoHave, birthDate, а не KEY mainSearch (gender, active, photoHave) Здесь чаще всего используются все поля, т.е. SELECT * FROM users WHERE gender='M' AND active != 'D' AND photoHave != 0 как я понял эксперементальным путем если создавать раздельные индексы по 1 полю то будет использоватся только 1 выдающий минимальное кол-во записей. вот Explain Код: plaintext 1. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2006, 13:35:43 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
не, что-то у Вас там не то :) Проследите в списке задач когда там висят updat-ы в локе - кто их лочит? В колонке command - если locked, значит не выполняются, ждут пока закончится какой-то другой, который в это время выполняется -- Dmitry ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2006, 18:17:35 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
MegaTron... INNO DB не предлагать нет ее в mySql 3.23 :( Не уверен... Я слышал, с выходом 4.0 или 4.1 шел пач для 3.23 для InnoDB, поищите... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2006, 21:49:39 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
InnoDB с версии 3.23.34, если не ошибаюсь... только его явно нужно в конфиге включать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2006, 13:57:18 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
MegaTron Как я понимаю это происходит из-за того что в процессах всегда висит 10-50 запросов вида Код: plaintext Ну так low же priority! http://dev.mysql.com/doc/refman/5.0/en/update.html If you use the LOW_PRIORITY keyword, execution of the UPDATE is delayed until no other clients are reading from the table. 129 секунд запрос ждёт, когда из таблицы перестанут читать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2006, 14:01:26 |
|
||
|
Приведение в нормальный вид таблицы Логинов
|
|||
|---|---|---|---|
|
#18+
DocAl MegaTron [quot http://dev.mysql.com/doc/refman/5.0/en/update.html%5D]http://dev.mysql.com/doc/refman/5.0/en/update.html] If you use the LOW_PRIORITY keyword, execution of the UPDATE is delayed until no other clients are reading from the table. 129 секунд запрос ждёт, когда из таблицы перестанут читать. ммм. это понятно, я сам прописывал туда lowPriority как я понимаю происходит так, накапливается nnn-update которые ждут прекращения чтения, в один момент записываются в базу, тем самым ускоряя запись из преймуществ: быстрее записывается n-записей чем по одной не блокирует операции чтения при множестве update недостатки: update подвисая и накапливаясь занимают по одному connection каждый или я не прав ? Вообщем скажите Low_Priority это хорошо для некритичных данных или это всегда плохо ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2006, 15:36:27 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=33477697&tid=1853163]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 198ms |
| total: | 331ms |

| 0 / 0 |
