Клубове Дир.бг
powered by diri.bg
търси в Клубове diri.bg Разширено търсене

Вход
Име
Парола

Клубове
Dir.bg
Взаимопомощ
Горещи теми
Компютри и Интернет
Контакти
Култура и изкуство
Мнения
Наука
Политика, Свят
Спорт
Техника
Градове
Религия и мистика
Фен клубове
Хоби, Развлечения
Общества
Я, архивите са живи
Клубове Дирене Регистрация Кой е тук Въпроси Списък Купувам / Продавам 13:54 22.06.24 
Компютри и Интернет
   >> Бази данни
*Кратък преглед

Страници по тази тема: 1 | 2 | >> (покажи всички)
Тема Re: MySQL и локване на таблици при сложна SQL заявнови [re: Ц++]  
АвторДядoMpaз (Нерегистриран)
Публикувано18.05.06 15:24



InnoDB има и в MySQL след 3.23.34a, така че може да не ти се наложи да ъпгрейдваш много.

Колкото до заявката - не се бях сетил за тоя случай . Можеш да направиш заявката

select inventory.* from employee
left join inventory on inventory.employee_id=employee.employee_id
where employee.department_id=123 and inventory.employee_id is not NULL

Ако имаш индекс на inventory.employee_id няма да има почти никакво забавяне. Все пак използвай EXPLAIN за да видиш как точно ще сте изпълни заявкатa.



Тема Там е разликата с LEFT JOINTнови [re: Ц++]  
Автор bira_more (бира)
Публикувано18.05.06 15:25



ако е с where - няма да имаш полетата с NULL.
Ако си с left joint, трябва допълнително - where my_field IS NOT NULL

Bеer? Mоre?




Тема Re: дребно допълнениенови [re: ДядoMpaз]  
Автор salle (един такъв)
Публикувано18.05.06 15:34



... но съществено откъм бързодействие


"При големи таблици това може да отнеме доста време така че ... по добре си създай нова таблица INNODB и копирай данните в нея на групи от по 1000-2000, че да избегнеш locks."


INSERT INTO innodb_tbl SELECT * FROM myisam_tbl ORDER BY <Primary_Key>;

Скоростта на INSERT в InnoDB много силно се влияе от реда на вмъкване. Най-бързо е ако редовете са подредени според първичния ключ. Ако са разбъркани може да стане мнаго по-бавно. Виждал съм да се бави да 15 пъти! При големи таблици разликана може да е между няколко дена и няколко часа така, че си заслужава да се има предвид

(С малко четене на документацията е очевидно защо има такава зависимост)



Тема Re: Само да попитам ..нови [re: Ц++]  
Автор salle (един такъв)
Публикувано18.05.06 15:44



Не е много добра идея да разчиташ на оптимицатола да преобразува заявките.

Разликата между LEFT (OUTER) и обикновения (INNER) е съществена както явно знаеш и просто не е здравословно да използваш не това което ти трябва.

ОЩЕ повече ако минеш на InnoDB

InnoDB заключва както на ниво ред така и на ниво таблица.

Когато заявката се опитва да заключва отделни редове и те станат "много" InnoDB започва да изпитва проблеми.

В определени ситуации можеш много бързо да се убедиш, че заключването на цяла таблица както при MyISAM може да е многократно по-бързо от заключването на Всички Редове както може да се случи в InnoDB.

Особено с LEFT JOIN. При него както знаеш лявата таблица се претърсва цялата.



Тема Re: дребно допълнениенови [re: salle]  
АвторДядoMpaз (Нерегистриран)
Публикувано18.05.06 18:41



Всъщност това което предложих беше да пусне един цикъл от сорта на

for(x=0;x<[num_rows];x+=1000){
INSERT INTO innodb_tbl SELECT * FROM myisam_tbl ORDER BY <Primary_Key> LIMIT x,x+1000;
}

Така ще избегне локването на цялата таблица за времето на копирането. Това разбира се работи само при положение че някой междувременно не променя по старите записи. Иначе забавянето при INSERT идва основно от индексите, така ако се търси скорост на копиране на данните е по-добре новата таблица да е със спряни индекси:
ALTER TABLE new_table DISABLE KEYS;
INSERT ...;
ALTER TABLE new_table ENABLE KEYS;



Тема Re: Само да попитам ..нови [re: salle]  
АвторДядoMpaз (Нерегистриран)
Публикувано18.05.06 18:50



"Особено с LEFT JOIN. При него както знаеш лявата таблица се претърсва цялата."

Хъм - тук не си много прав. MySQL прави full table scan при Left JOIN само ако няма индекс който да ползва в ON или в WHERE клаузите.

http://dev.mysql.com/doc/refman/4.1/en/how-to-avoid-table-scan.html



Тема Re: Само да попитам ..нови [re: ДядoMpaз]  
Автор salle (един такъв)
Публикувано18.05.06 20:20



Е очевидно не се изразих съвсем ясно.

Независимо дали търси само в индекс или не накрая в резултатите трябва да се изведат колонките от всички редове в таблицата.

Да ако всичите изброени колонки са част от индекс стойностите могат да се извадят от индекса, но пак са всички.

И разбира се с уговорката, че зависи от това какво точно има във WHERE клаузата де. Виждал съм "сериозни" продукти които изпращат огромни заявки с по много закаечни таблици и куп сложнотии и накрая на 50-тия ред:

... WHERE .... t1.id = t2.id AND t1.id = 1 AND t2.id = 0 ...

Да питаш после що са му плащали заплата на този дето го е писал



Тема Re: дребно допълнениенови [re: ДядoMpaз]  
Автор salle (един такъв)
Публикувано18.05.06 20:36



"Това разбира се работи само при положение че някой междувременно не променя по старите записи."

т.е. цялото ти предложение би трябвало да изглежда ей така:

LOCK TABLES myisam_tbl READ;

for(x=0;x<[num_rows];x+=1000){
INSERT INTO innodb_tbl SELECT * FROM myisam_tbl ORDER BY <Primary_Key> LIMIT x,x+1000;
}

UNLOCK TABLES;



С което цялото упражнение става малко безсмислено защото крайния ефект е пак като на единичен INSERT без цикъл.


ALTER TABLE new_table DISABLE KEYS;

Пропускаш факта, че DISABLE / ENABLE KEYS работи само с MyISAM




Страници по тази тема: 1 | 2 | >> (покажи всички)
*Кратък преглед
Клуб :  


Clubs.dir.bg е форум за дискусии. Dir.bg не носи отговорност за съдържанието и достоверността на публикуваните в дискусиите материали.

Никаква част от съдържанието на тази страница не може да бъде репродуцирана, записвана или предавана под каквато и да е форма или по какъвто и да е повод без писменото съгласие на Dir.bg
За Забележки, коментари и предложения ползвайте формата за Обратна връзка | Мобилна версия | Потребителско споразумение
© 2006-2024 Dir.bg Всички права запазени.