ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Partitioning again..
25 сообщений из 57, страница 1 из 3
  1  все
Partitioning again..
    #38551737
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
Есть таблица, записей 7кк

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE TABLE user_file (
  id char(13) NOT NULL
  ....
  PRIMARY KEY (id),
  ....
)
PARTITION BY KEY (`id`)
(
    PARTITION p0 ENGINE = INNODB,
    PARTITION p1 ENGINE = INNODB,
    ....
    PARTITION p24 ENGINE = INNODB
)



Запрос COUNT(*) без партиционирования выполняется 0.7 секунд, с 25 партициями = 10 секунд.
Вопрос собстна в том, почему так долго и можно ли что покрутить, чтобы хоть как-то улучшить время?
PS^ По сути проблема со всеми запросами которые аггрегируются, не то чтобы они совсем плохо работает, но вот где данных надо посчитать мало, выполняются очень быстро, но если много, то все, может какого буфера не хватает...
...
Рейтинг: 0 / 0
06.02.2014, 13:08:22
| Ответить | Цитировать | Написать  
Partitioning again..
    #38551755
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
Гмм, причем на линуксовом сервере версии 5.5.34 эти 10 секунд.
На другом виндовом 5.6.14 за 1.2 секунды выполняется. Правда тут записей меньше (5кк здесь)
...
Рейтинг: 0 / 0
06.02.2014, 13:16:30
| Ответить | Цитировать | Написать  
Partitioning again..
    #38551763
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Hettможет какого буфера не хватаетМожет, innodb_buffer_pool_size не хватает...
...
Рейтинг: 0 / 0
06.02.2014, 13:21:03
| Ответить | Цитировать | Написать  
Partitioning again..
    #38551781
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
На серверах стоит 12G на линуксе, на виндовом (где гораздо быстрее работает) - 4G
...
Рейтинг: 0 / 0
06.02.2014, 13:30:45
| Ответить | Цитировать | Написать  
Partitioning again..
    #38551783
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
Сейчас скачаю на виндовый полную табличку в 7кк и сравню
...
Рейтинг: 0 / 0
06.02.2014, 13:31:11
| Ответить | Цитировать | Написать  
Partitioning again..
    #38551786
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
Повторное время такое же большое?
В плане запроса что-нибудь интересное есть?
...
Рейтинг: 0 / 0
06.02.2014, 13:31:56
| Ответить | Цитировать | Написать  
Partitioning again..
    #38551794
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
Да повторное примерно такое же, раз по 5-10 запускл, ничего не меняется.

SIMPLEfh_user_fileindex(null)IX_user_file_abuse_status1(null)7476871Using index

Он похоже просто берет самый маленький индекс

Код: sql
1.
2.
 abuse_status tinyint(4) NOT NULL DEFAULT 0,
INDEX IX_user_file_abuse_status (abuse_status),



Вот с виндового:

SIMPLEfh_user_fileindex(null)IX_user_file_abuse_status1(null)5202505Using index
...
Рейтинг: 0 / 0
06.02.2014, 13:36:53
| Ответить | Цитировать | Написать  
Partitioning again..
    #38551799
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
HettОн похоже просто берет самый маленький индексПравильно, оно так и должно быть.

Попробуйте выполнить OPTIMIZE TABLE для это таблицы?
innodb_file_per_table, надеюсь, включена была до создания этой таблицы?
...
Рейтинг: 0 / 0
06.02.2014, 13:40:26
| Ответить | Цитировать | Написать  
Partitioning again..
    #38551805
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
Эту таблицу я создал только что, специально для теста и перекинул данные, думаю там нечего оптимизировать на данный момент...
innodb_file_per_table включен.
...
Рейтинг: 0 / 0
06.02.2014, 13:48:14
| Ответить | Цитировать | Написать  
Partitioning again..
    #38551814
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
В запросе точно только COUNT(*), без ничего больше?
...
Рейтинг: 0 / 0
06.02.2014, 13:50:54
| Ответить | Цитировать | Написать  
Partitioning again..
    #38551835
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
Код: sql
1.
2.
  SELECT COUNT(*) 
    FROM fh_user_file



Да, вот
...
Рейтинг: 0 / 0
06.02.2014, 14:04:01
| Ответить | Цитировать | Написать  
Partitioning again..
    #38551844
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
Ну COUNT() это как простейший пример, вообще проблем с любым аггрегирующим запросом.
...
Рейтинг: 0 / 0
06.02.2014, 14:07:04
| Ответить | Цитировать | Написать  
Partitioning again..
    #38552963
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
Залил на виндовый 7.5кк записей, запрос на каунт стал выполняться 5 секунд.
Сейчас буду пробовать на работу с 10 партишенами (было 25)
...
Рейтинг: 0 / 0
07.02.2014, 11:18:35
| Ответить | Цитировать | Написать  
Partitioning again..
    #38553385
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
Чудеса
С 10 партишенами время выполнения 7 секунд, с 25 - 5
Если данных чуть меньше (4.5кк), то 1 секунда.
...
Рейтинг: 0 / 0
07.02.2014, 14:06:19
| Ответить | Цитировать | Написать  
Partitioning again..
    #38554272
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Hett,

видишь ли, дорогой виртуальный друг, то, как работает запрос немного зависит от того, что это за запрос. Чуть менее чем полностью. Поэтому вопрошать так без полного текста запроса и полного DDL не то что глупо, а попросту бессмысленно.
...
Рейтинг: 0 / 0
08.02.2014, 06:06:47
| Ответить | Цитировать | Написать  
Partitioning again..
    #38554273
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Hett
Код: sql
1.
2.
  SELECT COUNT(*) 
    FROM fh_user_file



Да, вот

такой запрос бессмысленен и оптимизировать его так же мало смысла.
...
Рейтинг: 0 / 0
08.02.2014, 06:09:44
| Ответить | Цитировать | Написать  
Partitioning again..
    #38554275
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Hett
Код: sql
1.
2.
  SELECT COUNT(*) 
    FROM fh_user_file



Да, вот

и еще. с чего ты взял что такой запрос должен ускоряется после партицирования? он должен наоборот замедляться, в твоем конкретно случае примерно в 25 раз, чуть менее. твои времена примерно такой картине и соответствуют.
...
Рейтинг: 0 / 0
08.02.2014, 06:15:59
| Ответить | Цитировать | Написать  
Partitioning again..
    #38554315
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
MasterZivон должен наоборот замедляться, в твоем конкретно случае примерно в 25 разПочему?
...
Рейтинг: 0 / 0
08.02.2014, 11:01:06
| Ответить | Цитировать | Написать  
Partitioning again..
    #38554317
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
MasterZivHett
Код: sql
1.
2.
  SELECT COUNT(*) 
    FROM fh_user_file




Да, вот

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

Почему он должен замедляться в 25 раз? В таком случае можно сказать что любые аггрегирующие запросы будут замедляться в n-раз.
Тогда за одно может и поведуете, почему в случае с 10 партишенами скорость еще хуже чем с 25-ю?
Чем, в данном случае поможет DDL?


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

автори еще. с чего ты взял что такой запрос должен ускоряется после партицирования?
Вообще, теоретически если предположить, он может ускоряться хотя бы за счет того, что запросы к каждому партишену параллелятся (именно такое слово употреблено в официальной документации). Но ладно, но на это я и не рассчитывал, в общем-то, пусть даже медленее, но не в 25 раз же...
...
Рейтинг: 0 / 0
08.02.2014, 11:05:46
| Ответить | Цитировать | Написать  
Partitioning again..
    #38554780
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Hett,

потому что запрос вида

SELECT COUNT(*)
FROM user_file

обрабатывает все партиции, а не одну.
Их у тебя 25. Будет соотв. в 25 раз больше.
Плюс накладуха на сборку общего результата из частных по каждой партиции (думаю, не очень большая).

Другое дело, что скан всего в одной таблице и 1/25-ой всего в одной партиции -- тоже разные вещи.
Но по крайней мере спуск в дереве таблиц точно в 25 раз будет помножен.

В любом случае, не понятоно с чего бы такому запросу ускорится от наличия партицый
...
Рейтинг: 0 / 0
09.02.2014, 01:59:38
| Ответить | Цитировать | Написать  
Partitioning again..
    #38554820
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
MasterZivИх у тебя 25. Будет соотв. в 25 раз больше.
А ниче, что партиции в 25 раз меньше?
...
Рейтинг: 0 / 0
09.02.2014, 07:39:41
| Ответить | Цитировать | Написать  
Partitioning again..
    #38555185
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
HettMasterZivИх у тебя 25. Будет соотв. в 25 раз больше.
А ниче, что партиции в 25 раз меньше?

ты вообще читаешь что я пишу?

еще раз, за счет чего по твоему запрос должен вдруг заработать быстрее после разбиения на партиции?

кстати, запрос дай.
...
Рейтинг: 0 / 0
10.02.2014, 02:06:10
| Ответить | Цитировать | Написать  
Partitioning again..
    #38556147
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hett
Участник
Дык я же говорю, я и не ждал ускорения и прекрасно понимал, что будет работать медленнее, но не в 10 раз же. Но вообще, если уж так подумать, то мог бы и быстрее, если бы он каждую партицию считал в другом потоке параллельно. Это я уже выше все писал, вы у меня уже по второму кругу одни и те же вопросы спрашиваете и кто тут читает кого, а кто кого нет, - вопрос еще спорный :)
Щас потестил на версии 5.6 под виндой, хоть 10 партиций, хоть 100, время одно, 5 секунд. На убунте в версии 5.5 почему-то 10 партишенов работали медленее чем 25.

Запрос

Код: sql
1.
2.
3.
SEELCT COUNT(*), SUM(size)
FROM user
WHERE user_id = :user_id



На продакшене запрос выполнялся раньше за 0.1 секунды, теперь 1.1 секунды. Да и вообще любые группирующие запросы в общем так себя проявили. Тот же

Код: sql
1.
SELECT COUNT(*) FROM tablename
...
Рейтинг: 0 / 0
10.02.2014, 18:16:09
| Ответить | Цитировать | Написать  
Partitioning again..
    #38556316
Aleksandr Kuzminsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aleksandr Kuzminsky
Гость
Hett,

А зачем Вам вообще partitions?
...
Рейтинг: 0 / 0
10.02.2014, 21:11:29
| Ответить | Цитировать | Написать  
Partitioning again..
    #38556618
Фотография многоразовый клон 26
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
многоразовый клон 26
Участник
miksoftHettОн похоже просто берет самый маленький индексПравильно, оно так и должно быть.

Попробуйте выполнить OPTIMIZE TABLE для это таблицы?
innodb_file_per_table, надеюсь, включена была до создания этой таблицы?

насколько я знаю, надо делать OPTIMIZE PARTITION
...
Рейтинг: 0 / 0
11.02.2014, 08:47:48
| Ответить | Цитировать | Написать  
25 сообщений из 57, страница 1 из 3
  1  все
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Partitioning again..
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=47&msg=38551783&tid=1835225]:
 0ms
get settings:
 6ms
get forum list:
 11ms
check forum access:
 2ms
check topic access:
 3ms
track hit:
 48ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 43ms
get tp. blocked users:
 1ms
others: 217ms
total:  341ms
созд. / загр.: 341ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]