наконец-то дошли руки...
структура данных:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE TABLE IF NOT EXISTS `T_PRODUCT` (
`id` int( 10 ) unsigned NOT NULL,
`price` decimal( 12 , 4 ) default NULL,
`is_product_of_day` tinyint( 3 ) unsigned NOT NULL default '0',
PRIMARY KEY (`id`),
KEY `is_product_of_day` (`is_product_of_day`)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251;
CREATE TABLE IF NOT EXISTS `T_PRODUCT_OF_DAY` (
`id` int( 10 ) unsigned NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=cp1251;
alter table T_PRODUCT_OF_DAY add constraint FK_POD foreign key (id)
references T_PRODUCT (id) on delete cascade on update cascade;
заполнял таким способом:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
<?php
...
for ($i= 1 ;$i< 100001 ;$i++)
{
$DB->executeQueryStr('insert into T_PRODUCT values('.$i.','.$i.','.((fmod($i, 1000 )== 0 )?'1':'0').')');
if ((fmod($i, 1000 ))== 0 )
{
$DB->executeQueryStr('insert into T_PRODUCT_OF_DAY values('.$i.')');
}
}
?>
грустновато, что MySQL всё же не Oracle, такой детальной статистики получить не удалось :( но всё же планы запросов:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
EXPLAIN SELECT *
FROM `T_PRODUCT_OF_DAY` pd
JOIN `T_PRODUCT` pr ON ( pr.id = pd.id )
+----+-------------+-------+--------+---------------+---------+---------+---------------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+---------+---------+---------------+------+-------------+
| 1 | SIMPLE | pd | index | PRIMARY | PRIMARY | 4 | NULL | 100 | Using index |
| 1 | SIMPLE | pr | eq_ref | PRIMARY | PRIMARY | 4 | emarket.pd.id | 1 | |
+----+-------------+-------+--------+---------------+---------+---------+---------------+------+-------------+
EXPLAIN SELECT *
FROM `T_PRODUCT` pr
WHERE pr.is_product_of_day = 1
+----+-------------+-------+------+-------------------+-------------------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+-------------------+-------------------+---------+-------+------+-------+
| 1 | SIMPLE | pr | ref | is_product_of_day | is_product_of_day | 1 | const | 99 | |
+----+-------------+-------+------+-------------------+-------------------+---------+-------+------+-------+
поэтому попробовал провести натурные испытания :)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
<?php
...
echo Util::getSystemTime().'<br>';
for ($i= 1 ;$i< 100001 ;$i++)
{
$DB->executeQueryStr('SELECT * FROM `T_PRODUCT_OF_DAY` pd JOIN `T_PRODUCT` pr ON ( pr.id = pd.id )');
}
echo Util::getSystemTime().'<br>';
for ($i= 1 ;$i< 100001 ;$i++)
{
$DB->executeQueryStr('SELECT * FROM `T_PRODUCT` pr WHERE pr.is_product_of_day = 1');
}
echo Util::getSystemTime();
?>
результат:
12:53:09.605
12:53:35.789
12:54:01.176
итого по скорости:
с доп.таблицей: 26.184 с
с индексом: 25.384 с (быстрее на 0,797 с, т.е. на ~3%)
по объёму занимаемых данных:
T_PRODUCT (100000 записей; Данные: 3,600 КБ; Индексы[2шт]: 1,552 КБ), т.е. 1,552/2 = 776 К накладных расходов (больше в ~47 раз)
T_PRODUCT_OF_DAY (100 записей; Данные: 16,384 байт), т.е. 16К накладных расходов
Резюме:
оба подхода, в данном случае, практически идентичны по производительности, доп.таблицы эффективнее по расходу дискового пространства, но несколько сложнее в использовании.
Эксперимент не учитывал влияние возможных потерь производительности, связанных с использованием языка PHP (интерпретация, библиотеки и т.п.).
Если есть замечания - с удовольствием учту и проведу эксперимент повторно.
---------------------------------------
Молодёжный научный семинар по во вопросам надёжности и гарантоспособности ПО
