Vampiro

Для 5к строк я инсертил бы новую, помечая предыдущую «удаленной». Что-то а-ля версионность получилось бы. После удовлетворения необходимости, старье можно подчистить.

SELECT  `company` , customer, COUNT(  `item` ) AS items
FROM  `test` 
GROUP BY company
HAVING COUNT(  `item` ) >10
ORDER BY COUNT(  `customer` ) DESC 

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

Вообще, запросы крайне сложно оптимизировать не имея перед глазами вообще ничего.
Покажите create table, explain extended… Ну да ладно, поворчали, и будет.

Если вы используете простые числовые значения в IN и сам запрос простой, как пуля, например

select * from test1 where ID in (1,2,5,3);

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

Если запросы сложнее (join, order by, union), то вас ждет печаль, а нас — более подробное описание задачи. Зачастую быстрее загрузить все ID во временную таблицу, и потом уже с ней работать. Чем ждать пока запрос с заменой обычного условия на IN отработает.

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

CREATE TABLE IF NOT EXISTS `test1` (
  `minVal` int(11) NOT NULL,
  `maxVal` int(11) NOT NULL,
  `price` int(11) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`price`),
  UNIQUE KEY `froms` (`minVal`),
  UNIQUE KEY `fr2` (`minVal`,`maxVal`)
) ENGINE=MyISAM;

заполним ее значениями для 100к множеств с шагом 5 (0..4,5..9,… ,100000..100005)

EXPLAIN SELECT * 
FROM  `test1` 
WHERE minval <=42000
ORDER BY minval DESC 
LIMIT 1

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE test1 range froms,fr2 fr2 4 NULL 9396 Using where

EXPLAIN SELECT * 
FROM  `test1` 
WHERE minval <=42000
AND maxval >=42000

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE test1 ALL froms,fr2 NULL NULL NULL 20001 Using where

Имеющий глаза — да увидит.

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

Вы же рисуете пользователю эти картинки, проходя циклом по всей выборке. Добавьте в УРЛ нужные данные.

можно не заморачиваться и сделать
user_id, message
А зачем вам возиться с id сообщений? Пользователь либо прочитал все уведомления, и ткнул кнопку «прочитано» (тогда очищаем message), либо не прочитал ничего. Кто-то выборочно читает уведомления и тискает на кнопки?

Но если вам очень хочется правильно + адимнку сообщений и прочие заморочки, то да, придется делать еще одну табличку.

Погуглите lib_mysqludf_sys, должно помочь.

Эм… может что-нить типа
create or replace VIEW forFastReports as select * from mySlowTable where added_at < date_sub(now(),INTERVAL 1 DAY);?

Я бы для оптимизации этой таблички сделал разбивку на PARTITIONS
либо по датам,
CREATE TABLE demo (col1 INT, tasks VARCHAR(255), col3 DATE)
PARTITION BY KEY(col3)
PARTITIONS 4;
либо по полю обработки
PARTITION BY LIST (id) (
PARTITION r0 VALUES IN (0),
PARTITION r1 VALUES IN (1),

Индекс по 0/1 быстрый, поскольку нужные вам записи хранятся первыми же в HASH (а я искренне надеюсь, что вы сделали HASH индекс, а не BTREE)

В общем случае, принципы построения индексов достаточно просты: индекс (кроме первичного) строится для ускорения запросов. Причем если есть WHERE по двум полям, то будет взят индекс, содержащий оба этих поля (если есть) и не важно сколько их там еще.

Другими словами, один индекс по полям «A, B, C» будет более «полезен» для запроса, содержащего некие условия по полям A и B, чем два отдельных индекса по полям «A» и «B».

Фактически, индексы A,B,C и A,C,D будут одинаковы в части поиска по полю «А». При поиске по полям А,B будет взят первый индекс. При поиске по полям A, C — второй.

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

Не бойтесь добавлять слово EXPLAN в тело запроса и смотрите какие индексы он использует. Порой оптимизатор использует fullscan даже при наличии индексов.