Большая таблица в MySQL - вопрос по оптимизации

Если не рассматривать процессор, то узкое место - MySQL.
Что делать? Как вариант - переезжать на другую БД.

совершенно глупый и бесполезный совет.

>1.6 млн.

это совсем не большая таблица для мускуля.

1.сделать индексы по полям.
2.что за железо?
3.my.cnf + mysqladmin variables+extend status+ RSS памяти для мускуля из топа в студию.

индексы то присутствуют? У меня как раз таблица под рукой: 1 652 853 записей, COUNT(id) занимает 0,0003 секунды без кеша.
Или ты на тостере мускуль запустил?

Почему же глупый?
Рано или поздно придется менять БД, ибо бесконечно оптимизировать MySQL не получится.
Кто знает, может скоро база вырастет раз в 50-100.
Надо на несколько ходов вперед думать.

вот твоя логика : «У машины проколото колесо - надо покупать другую машину или вобще лучше танк - кто знает, вдруг на дорогах будут еще гвозди»

Рано или поздно придется менять БД

почему это вдруг?

ибо бесконечно оптимизировать MySQL не получится.

но провести базовую и необходимую оптимизацию(а в данном случае, это скорее просто настройка сервера под задачу) - первое дело.

а какой engine? совсем не для всех каунт быстрая операция.

mysql> select count(flow_id) from flows;
+----------------+
| count(flow_id) |
+----------------+
|      216745337 | 
+----------------+
1 row in set (0.00 sec)

бугага.

это myisam что-ли? :)

индексы, table partitioning, поиграться с оптимизацией запросов, структурой таблицы итп.

ну да, а что такого?

ну да, а что такого?

Ну, вот, пример. Одна и та же таблица. punbb - оно в myisam. punbb4 - оно в innodb:

mysql> use punbb;
mysql> select count(*) from posts;
+----------+
| count(*) |
+----------+
|  2074620 | 
+----------+
1 row in set (0.00 sec)

mysql> use punbb4;
mysql> select count(*) from posts;
-- ...
-- за несколько минут не дождался.

О! В таком варианте дождался:

mysql> select count(id) from posts;
+-----------+
| count(id) |
+-----------+
|   2037398 | 
+-----------+
1 row in set (6 min 45.54 sec)

Это на Q9440 с 16Гб оперативы и с 8(кажется)Гб отданными под innodb-буфер :)

До кучи:
[code]
$ mongo

use BALANCER_BOARD

db.posts.count()

2070268
[/code]

работает мгновенно, т.е. <0.1сек. К сожалению, не знаю, как в mongodb измерять время выполнения операции.

>6 min 45.54 sec

жестоко. Ну и в топку тогда этот innodb :)

>Ну и в топку тогда этот innodb :)

Он полезен, когда нужны транзакции и взаимная целостность объектов. Но в целом - да. Для больших таблиц он ужасен :D - http://www.linux.org.ru/forum/talks/4350880

Гы. В прододжение MongoDB

> db.posts.find({ class_name : 'forum_post'}).count()
2070268
> db.posts.find({ poster_ip : '194.85.224.35'}).count()
4122

Это два миллиона записей без индексов. Первый запрос - около секунды. Второй - секунд 5. Повторяю: без индексов! :D

С индексом - мгновенно. Создание индекса для IP - около 10 секунд.

:-) тоже знаете ли :-)
mysql> select count(ip) from squid;
+-----------+
| count(ip) |
+-----------+
| 12100813 |
+-----------+
1 row in set (46.98 sec)

root@DBServ:/etc/squid/ban# uname -a
Linux DBServ 2.6.29.6-smp #2 SMP Mon Aug 17 00:52:54 CDT 2009 i686 Intel(R) Xeon(TM) CPU 2.80GHz GenuineIntel GNU/Linux