Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > MySQL > Частые drop & create table

Автор: Suic2 11.10.2012, 17:42

Если я очень часто(раз в несколько секунд) удаляю таблицу и создаю заново это плохо? Или это никак не влияет на состояние БД и такое решение вполне жизнеспособно?  Делаю так: Код START TRANSACTION; DROP TABLE IF EXISTS dhcp_leases; CREATE TABLE dhcp_leases(id INT NULL AUTO_INCREMENT, ip TINYTEXT, mac VARCHAR(18), starts VARCHAR(20), ends VARCHAR(20), sw_mac VARCHAR(18), sw_addr TINYTEXT, sw_port TINYINT, PRIMARY KEY (id)) ENGINE = InnoDB; INSERT INTO dhcp_leases (ip, starts, ends, mac, sw_mac, sw_addr, sw_port) VALUES $sql COMMIT;

Автор: Akina 11.10.2012, 19:43

А нахрена? TRUNCATE гораздо быстрее.

Автор: Zloxa 11.10.2012, 22:13

DDL работают в транзакции?

Автор: Akina 11.10.2012, 22:43

Цитата(Zloxa @  11.10.2012,  23:13 ) DDL работают в транзакции?     Угу.. правда, они фиксируют её.

Автор: Zloxa 12.10.2012, 09:02

Цитата(Akina @  11.10.2012,  23:43 ) Угу..  Неа...    Цитата(Akina @  11.10.2012,  23:43 ) правда, они фиксируют её.  Как правило, они фиксируют ее перед, потому в транзакции не работают

Автор: Akina 12.10.2012, 09:06

Zloxa, я имел в виду, что синтаксически это не ошибка.

Автор: Suic2 12.10.2012, 09:50

Значит нет смысла в этой транзакции? Просто хотел чтобы данные были всегда доступны, а если я сначала очищу таблицу, а между её заполнением к ней поступит запрос и данных не обнаружится будет печально:( Как в этом плане работает truncate?

Автор: Akina 12.10.2012, 09:57

Цитата(Suic2 @  12.10.2012,  10:50 ) Значит нет смысла в этой транзакции? В ЭТОЙ - никакого. Цитата(Suic2 @  12.10.2012,  10:50 ) если я сначала очищу таблицу, а между её заполнением к ней поступит запрос и данных не обнаружится будет печально:( Гм... какой смысл создавать транзакцию, в принципе не понимая, что это такое? Цитата(Suic2 @  12.10.2012,  10:50 ) Как в этом плане работает truncate? Смотря какой уровень изоляции выбран...

Автор: Zloxa 12.10.2012, 10:31

Цитата(Akina @  12.10.2012,  10:57 ) Смотря какой уровень изоляции выбран...  Truncate это тоже DDL, емнип

Автор: Akina 12.10.2012, 10:39

Да, действительно, с версии 5.0.8 TRUNCATE TABLE тоже коммиттит изменения....

Автор: Suic2 12.10.2012, 10:40

Цитата(Akina @  12.10.2012,  09:57 ) Гм... какой смысл создавать транзакцию, в принципе не понимая, что это такое? чтобы спросить на форуме и меня наставили на путь истинный   извиняюсь если мой бредовый пример вас смутил

Автор: Akina 12.10.2012, 10:47

Цитата(Suic2 @  12.10.2012,  11:40 ) чтобы спросить на форуме и меня наставили на путь истинный   Ну на форуме это вызывает... ммм... некоторое удивление... почему бы не прочитать хотя бы основы в документации?  Кстати... а сколько записей максимально может быть в этой таблице? а то ведь delete from dhcp_leases на небольшой таблице будет достаточно быстрым (особенно если её на Memory Engine)...

Автор: Suic2 12.10.2012, 10:52

10-20 тысяч

Автор: Akina 12.10.2012, 10:54

И что, изменений настолько много, что дешевле грохнуть и пересоздать? не понимаю...

Автор: Zloxa 12.10.2012, 10:56

Цитата(Suic2 @  12.10.2012,  10:50 ) Просто хотел чтобы данные были всегда доступны, а если я сначала очищу таблицу, а между её заполнением к ней поступит запрос и данных не обнаружится будет печально:( Здесь все зависит от уровня изоляции транзакции в котором работает читающая сессия. Вы знаете в каком она работает? Можете как-то повлиять на уровень ее изоляции?  Если читающая сессия работает в read uncommited, и вы не можете этого изменить, ваши попытки тщетны. Если читающая сессия рабоатет в read commited - detete / insert в помощь Если честно, затруднился бы ответить что прочитает MySQL сессия, читающая в repeatable read, serializable после truncate в другой сессии. Скорее всего ожидания не оправдаются. Транкейт рассогласует чужую транзакцию. Хорошо если эксепшн поднимится, но зная о "дружелюбности" MySQL к пользователю, думаю - врядли. Оракл вот перед транкейтом пассует. Тоже с-ка эксепшна не поднимает. Сессия 1 Код SQL> create table test as select 1 val from dual;   Table created SQL> set transaction isolation level serializable;   Transaction set SQL> select * from test;          VAL ----------          1 Сессия 2 Код SQL> delete from test;   1 row deleted SQL> commit;   Commit complete SQL> select count(*) from test;     COUNT(*) ----------          0   сессия 1 Код SQL> select * from test;          VAL ----------          1   сессия 2 Код SQL> truncate table test;   Table truncated   сессия 1 Код SQL> select count(*) from test;     COUNT(*) ----------          0

Автор: Suic2 12.10.2012, 10:58

раз в несколько минут dhcp сервер продляет время аренды, тоесть меняется каждую секунду около 160 записей, некоторые из них пропадают, появляются новые Добавлено через 12 минут и 24 секунды Цитата(Zloxa @  12.10.2012,  10:56 ) Вы знаете в каком она работает? Можете как-то повлиять на уровень ее изоляции?  если верить гуглу по умолчанию стоит REPEATABLE READ SET TRANSACTION ISOLATION LEVEL READ COMMITTED; так вроде

Автор: Zloxa 12.10.2012, 11:33

Гугл то откуда знает какой режим изоляции использует ваше приложение?

Автор: Suic2 12.10.2012, 11:36

если я не выставлял самостоятельно его, то он будет по умолчанию я так думаю. а я его не выставлял точно Код mysql> SHOW VARIABLES LIKE '%tx_isolation%'; +---------------+-----------------+ | Variable_name | Value           | +---------------+-----------------+ | tx_isolation  | REPEATABLE-READ | +---------------+-----------------+ 1 row in set (0.00 sec)

Автор: Akina 12.10.2012, 11:38

Цитата(Suic2 @  12.10.2012,  11:58 ) раз в несколько минут dhcp сервер продляет время аренды, тоесть меняется каждую секунду около 160 записей, некоторые из них пропадают, появляются новые Insert ... On duplicate key Update ... И не страдайте ерундой.

Автор: Suic2 12.10.2012, 11:42

Цитата(Akina @  12.10.2012,  11:38 ) Insert ... On duplicate key Update ... И не страдайте ерундой.  а как быть с теми кого уже быть не должно в базе?

Автор: Zloxa 12.10.2012, 11:52

Цитата(Suic2 @  12.10.2012,  12:36 )  а я его не выставлял точно Когда я задавал вопрос "знаете ли, можете ли" я имел в виду в первую очередь тот кейс, что читающее приложение написано не вами, и вы не имеете доступ к исходному коду. Такое тоже бывает. И часто. Если же приложение написано вами, то вы, даже если не знаете то точно уж можете  Добавлено через 3 минуты и 21 секунду Друзья, а можете воспроизвести приведенный мной тесткейс для оракла, на масе. Ейбоху жуть как интересно чотам да как будет

Автор: Akina 12.10.2012, 12:28

Цитата(Suic2 @  12.10.2012,  12:42 ) а как быть с теми кого уже быть не должно в базе?  Ну так вторым запросом удаляйте записи, у которых истекло время аренды. Как раз эти два запроса распрекрасно оборачиваются в транзакцию. Добавлено через 9 минут и 6 секунд Zloxa Если в сессии 1 начать транзакцию, то сессия 2 будет висеть на delete from test; до её завершения.

Автор: Zloxa 12.10.2012, 12:47

Цитата(Akina @  12.10.2012,  13:28 ) то сессия 2 будет висеть на delete from test; до её завершения. Спасибо, я и сам так думал, пока полагал что мася блокировочник, но только после того, как узнал что мася еще и http://dev.mysql.com/doc/refman/5.6/en/innodb-consistent-read.html, стал очень сомневаться. Цитата Consistent read is the default mode in which InnoDB processes SELECT statements in READ COMMITTED and REPEATABLE READ isolation levels. A consistent read does not set any locks on the tables it accesses, and therefore other sessions are free to modify those tables at the same time a consistent read is being performed on the table а что в кейсе с транкейтом? Встанет на блокировке? Цитата(Akina @  12.10.2012,  13:28 ) Как раз эти два запроса распрекрасно оборачиваются в транзакцию. Вот только не фак что это действительно надо, если чтение идет в repeatable read

Автор: Zloxa 12.10.2012, 13:26

Цитата(Zloxa @  12.10.2012,  13:47 ) Вот только не фак Подумал, надо  Наверное

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)