Время изменения таблицы

[demis]

Время изменения таблицы

Странная проблема.
Использую для проверки времени изменения таблицы
SHOW TABLE STATUS
(Время изменения файла данных из мануала).
Но при реальном изменение, даже через пхпадмин пробывал, время остаеться прежним. Хотя изменения с радостью принимает. Попробывал UPDATE,INSERT,DELETE. Время изменения не меняеться ни на секунду (
Как будто все в оперативке храниться, такое может быть?

 

[tony2001]

1) зачем тебе время изменения _таблицы_ ?
2) заведи себе поле TIMESTAMP и выбирай самую последнюю дату.

 

[demis]

Originally posted by tony2001
1) зачем тебе время изменения _таблицы_ ?
2) заведи себе поле TIMESTAMP и выбирай самую последнюю дату.

1) Файлы кеширую. Если таблица не изменена, то инклюдим закешированный в файл вывод, иначе, создаем этот файл.
Тривиальная система кеширования. В моем случае она увеличивает скорость в 100 раз.
2) Из-за того, что база слишком большая, не хочется заводить поле и после по нему делать выборки, это тоже займет немало времени, как я предпологаю.

Ведь на проверку изменения времени файла требуется очень мало времени, к чему я и стремлюсь.
tony2001 , не кажется странным поведение базы?

 

[tony2001]

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

 

[ForJest]

Если данные меняются относительно редко (скажем реже чем раз в секунду) то тебе стоит сделать как говорит Тони. В этом случае накладные расходы на обновление индекса не будут значимыми.

EXPLAIN SELECT MAX(ts_field) FROM my_table;

 

[demis]

Originally posted by ForJest
Если данные меняются относительно редко (скажем реже чем раз в секунду) то тебе стоит сделать как говорит Тони. В этом случае накладные расходы на обновление индекса не будут значимыми.

EXPLAIN SELECT MAX(ts_field) FROM my_table;

Спасибо, завтра попробую... Но все равно эта операция гораздо дольше будет выполняться чем простое взятие информации о файле. Можно ли как-то в ручную заставить сохранить результаты обнавления на диск??? Обновляется действительно очень редко, но хотелось бы после обновления всетаки заставить сохранить результат на диск )
очень хочется помаксимуму уменьшить нагрузку на сервер БД.

 

[ForJest]

FLUSH TABLES - если есть привелегии.

1. Вариант с полем дополнительным.
+ нет после каждого изменения у тебя в timestamp хранится время актуального изменения записи.
- дополнительные расходы на индекс и собственно поле
- индекс будет кэшироваться в MySQL - это дополнительный расход ресурсов

2. Вариант с SHOW TABLE STATSU
+ Извлекается только системная ин-ция о таблице
- Нужно мускьку заставить перед выполнением сделать эти данные актуальными.
- это нужно делать после каждой операции изменения данных и с помощью FLUSH TABLES будут сбрасываться _все_ таблицы.

3. Композитный вариант
Заводишь таблицу с помощью show tables
[sql]
CREATE TABLE last_update(
table_name CHAR(50) NOT NULL PRIMARY KEY,
ts_lastchage TIMESTAMP
);
[/sql]
раз в N минут (допустим 30) делаешь FLUSH TABLES (или SELECT MAX()) после чего заносишь полученный с помощью SHOW TABLE STATUS (или результатов SELECT MAX()) в таблицу.
После этого ты можешь пользоваться этими данными как
[sql]
SELECT ts_lastchange FROM last_update WHERE table_name = '%s'
[/sql]

 

[demis]

К сожалению привелегий нет, придеться timestamp юзать наверное. Думаю третий вариант тоже рассмотреть. 30 минут неохота делать, хочеться сразу. Только придется после всех скриптов где апдейты, инсерты, дилиты аккуратно обновление к этой таблице прилепить.
Вообщем, буду тестировать по скорости.

А сами запросы кешировать можно вручную? и есть ли смысл?
Например, закешировать самый ресурсоемкий запрос и юзать его из кеша после?

 

[ForJest]

Вообщем, буду тестировать по скорости.

Оптимизировать нужно, когда будет известно узкое место .

Например, закешировать самый ресурсоемкий запрос и юзать его из кеша после?

С этим неплохо справляется MySQL с четвёртой версии самостоятельно.

 

[demis]

Всем спасибо!
Мои исследования:
таблица небольшая, но всеравно время заметно
кол-во 314
без индекса max(ts) выбирался 0,0025
с индексом 0,0003
И если mysql все это дело кеширует, то вообще супер.
Так что юзайте timestamp, не так это и страшно, как кажется на первый взгляд.