Алексей Скахин

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

Еще как вариант можно hash партиционировать по uid. Тогда не потеряется скорость ни чтения, ни записи.

Можно сократить на 1 sql запрос

UPDATE table SET count+=1 WHERE ( param1, param2, param3 ) IN( SELECT param1, param2, param3 FROM table WHERE status=@status ) and status=0;
DELETE FROM table  WHERE ( param1, param2, param3 ) IN( SELECT param1, param2, param3 FROM table WHERE status=@status ) and status=@status;

Ну или так, без execute immediate

select rsre.TERM_MIN
      into l_min
      from my_settingse_rule rsre 
      where  rsre.id = id
      and 
      ( (rsre.COLUMN1 =1 and academ_level_id =1) or (rsre.COLUMN2 =1 and academ_level_id =2) or academ_level_id > 2 )

По хранилищам пока видел только одну: Oracle9iR2 разработка и эксплуатация хранилищ баз данных (Лилиан Хоббс Сьюзан Хилсон Шилла

Попробуйте отселектить значение в переменную mysql https://dev.mysql.com/doc/refman/5.0/en/user-varia... , а потом сделать ее инсерт.
Последовательное выполнение, должно решить проблему.

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

SELECT * FROM T WHERE (title, value) IN(('Новая', '0'), ('Выполнена', '1'));
и т.д.

Оптимизировать тут надо не запрос, а таблицу:
* отключать все индексы, чтобы они не перестраивались
* отключать FK, чтобы не было проверок целостности. (зависимости чистить вручную)
* Если записей милионы, то можно сделать партиции и чистить партиции ALTER TABLE t1 TRUNCATE PARTITION p0; (пимер из Oracle)
* Отключать все триггеры
и т.д. нужно ограничить влияние всех внешних факторов.

Може так

SELECT u.*,
(
  SELECT MAX(o1.date) 
  FROM orders o
  INNER JOIN orders o1
   ON(o1.user_id = o.user_id
       AND o1.date < o.date)
  WHERE 
    o.user_id = u.id
) as date
FROM users u

Почитайте про KEEP (DENSE_RANK FIRST ORDER BY date_field ASC) или про OVER (PARTITION BY person_key ORDER BY date_field)

Может использовать UNION или делать JOIN `param_value` столько раз, сколько param_name ?

Я бы лучше сделал без цикла:
* иерархическим запросом сделал бы таблицу с годами
В oracle это так:

select level from dual
connect by level < 2000

* Приджойнил бы эту таблицу к вашему запросу

Плюсом - скорость, т.к. нет никаких процедур.

Почему не написать так:

SELECT SUM( t.ts_inserted - t.ts_cleared ) secs
FROM table t
WHERE t.device_id = ?
AND ? BETWEEN t.ts_cleared AND t.ts_inserted

Можно еще CASE WHEN писать в ORDER

Может сделать view в sqlite базе:

SELECT * FROM table t1
WHERE t1.id IN (
  SELECT MAX(t2.id)
  FROM table t2
  GROUP BY t2.number
)

или

SELECT * FROM table t1
WHERE t1.id = (
  SELECT MAX(t2.id)
  FROM table t2
  WHERE t2.number = t1.number
)

Не знаю как в T-SQL, но в oracle можно так
1. UNION

select id, sum(summa) over	(order by id rows between unbounded preceding and  1 preceding ) as Itog from [dbo].[Operations]
union all
select NULL, SUM(summa) from [dbo].[Operations]

2. Посчитать общий итог в отдельный столбец

select	[id], [data], [summa], 
		sum([summa]) over	(order by [id]
			rows between unbounded preceding and  1 preceding )
		as [Itog],
               sum([summa]) over	( ) as [Itog1]
from	[dbo].[Operations]

3. Можно посчитать подитог без аналитических функций (не знаю правда насколько поменяется производительность), а итоговую строку сформировать функцией rollup (oracle)

select d1.id, SUM(d2.summa)
from [dbo].[Operations] d1 left join [dbo].[Operations] d2
ON( d1.id > d2.id )
group by rollup(d1.id)
order by d1.id

хотя 3ий вариант счита сумму по подитогам, это не совсем та сумма)