Здравейте!
Имам MySQL версия 5.0.37. Създал съм си една таблица с продукти. Когато големината и набъбна (293000 записа) започнаха странни неща. При елементарен select * from products ORDER BY product_name ASC LIMIT 40000, 20
със съществуващ индекс по product_name заявката се изпълнява за 10 сек. Колкото първата стойност в LIMIT е по-голяма толкова по-бавно се изпълнява и обратно , колкото е по-малко толкова по-бързо. Ето я и структурата:
`product_id` int(11) NOT NULL auto_increment,
`vendor_id` int(11) NOT NULL default '0',
`product_parent_id` int(11) NOT NULL default '0',
`product_sku` varchar(64) NOT NULL default '',
`product_s_desc` varchar(255) default NULL,
`product_desc` text,
`product_thumb_image` varchar(255) default NULL,
`product_full_image` varchar(255) default NULL,
`product_publish` char(1) default NULL,
`product_weight` decimal(10,4) default NULL,
`product_weight_uom` varchar(32) default 'pounds.',
`product_length` decimal(10,4) default NULL,
`product_width` decimal(10,4) default NULL,
`product_height` decimal(10,4) default NULL,
`product_lwh_uom` varchar(32) default 'inches',
`product_url` varchar(255) default NULL,
`product_in_stock` int(11) NOT NULL default '0',
`product_available_date` int(11) default NULL,
`product_availability` varchar(56) NOT NULL default '',
`product_special` char(1) default NULL,
`product_discount_id` int(11) default NULL,
`ship_code_id` int(11) default NULL,
`cdate` int(11) default NULL,
`mdate` int(11) default NULL,
`product_name` varchar(64) default NULL,
`product_sales` int(11) NOT NULL default '0',
`attribute` varchar(200) default NULL,
`custom_attribute` varchar(200) NOT NULL,
`product_tax_id` tinyint(2) NOT NULL default '0',
`product_unit` varchar(32) default NULL,
`product_packaging` int(11) default NULL,
`child_options` varchar(45) default NULL,
`quantity_options` varchar(45) default NULL,
`child_option_ids` varchar(45) default NULL,
`product_order_levels` varchar(45) default NULL,
PRIMARY KEY (`product_id`),
KEY `idx_product_vendor_id` (`vendor_id`),
KEY `idx_product_product_parent_id` (`product_parent_id`),
KEY `idx_product_sku` (`product_sku`),
KEY `idx_product_ship_code_id` (`ship_code_id`),
KEY `idx_product_name` (`product_name`)
) ENGINE=MyISAM

Може ли някой да ми даде идея , защо може да се случва това?

П.С. На windows-ка машина инсталирах по-висока версия на mysql ефекта е същия

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Все едно та питаш защо водата е мокра ....

Замисли се как би изпълнил такава заявка на ръка.

SELECT ... ORDER BY product_name ASC LIMIT 40000, 20

Трябва да вземеш всичките 293000 реда, да ги сортираш по product_name и чак когато подредиш първите 40020 реда си готов.

Би трябвало да е очевидно, че колкото по-рано спреш толкова по малко работа.

При LIMIT 100, 20 ще спреш обработката след 120 сортирани реда, при LIMIT 1000, 20 след 1020


Друг е въпроса, че таблицата ти плаче за Нормализация.

Съдържаниет е скрито
Влезте за да го видите

Ами принципно си прав НО ако не се вземе в предвид че аз имам индекс по същото поле.Логично е ако аз изпълнявам тази заявка на ръка да си погледна индекса и да отброя 20 елемента от посочената в индекса позиция. Така няма да ми се налага да подредя и след това да отброя въпросните елементи. По отношение на нормализацията - да. Ще поработя по въпроса. Вълнува ме най-вече този проблем. Дай някаква идея ако имаш.

Редактирано от zipthis на 25.03.09 10:12.

Между другото , времето на следната заявка също прогресивно се увеличава
Select * from products where product_sku=.......
където има индекс по product_sku
Спрях всички други конекции към сървъра за да не е допълнително натоварен . Направо съм узадъчен !

Колкото и да те озадачава това, фактът че има индекс, не означава автоматично, че той ще бъде използван или пък че непременно заявката ще стане по-бърза.

Затова, най-добре ни пусни изхода от: EXPLAIN SELECT * FROM products WHERE product_sku=...

"Договор, подписан с Русия, струва по-малко от хартията, върху която е написан!" - Бисмарк

"Логично е ако аз изпълнявам тази заявка на ръка да си погледна индекса и да отброя 20 елемента от посочената в индекса позиция."

А как ще стигнеш до въпросната позиция в индекса? Може би си представяш индексите като масиви, но те не са а са B-дървета. Това при положение, че индекса въобще се използва.

Както Dakota ти е писал по-добре провери с EXPLAIN дали е така.

Съдържаниет е скрито
Влезте за да го видите

Първо мреси за корекцията :) "озадачава " Хахахаха. От бързане ......
А ето го и резултата.
mysql> explain select * from jos_vm_product ORDER BY product_name ASC LIMIT 40000, 20 ;
+----+-------------+----------------+-------+---------------+------------------+---------+------+--------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+----------------+-------+---------------+------------------+---------+------+--------+-------+
| 1 | SIMPLE | jos_vm_product | index | NULL | idx_product_name | 195 | NULL | 293109 | |
+----+-------------+----------------+-------+---------------+------------------+---------+------+--------+-------+
1 row in set (0.00 sec)

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

Редактирано от zipthis на 30.03.09 18:22.

Използва индекс

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Използва се индекс, таблицата не е толкова голяма. Защо е толкова бавно? Бъдете малко по-полезни. Дайте идея.

Това сега е нова тема

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите