Задавайте вопросы, мы ответим
Вы не зашли.
Задача такая: есть кластер MySQL (пока что две ноды, вся репликация работает, с этим нет никаких проблем). База из 80 таблиц, данных суммарно порядка 400мб.
при выполнении среднего по сложности запроса (с участием 4 таблиц, все поля по которым осуществляется связь и выборка имеют индексы) время выполнения достигает 80 секунд, тот же запрос на той же базе в MyISAM укладывается в миллисекунды. Есть подозрение, что индексы кластер по каким-то причинам не использует, но создает и удаляет свободно.
Что еще заметил - в phpMyAdmin cardinality индексов равно количеству записей в таблицах, несмотря на то, что есть ряд параметров с уникальностью в 5 значений. Да, и там же - при просмотре всех таблиц базы не удается просчитать количество записей в каждой из них. В MyISAM количество записей считает.
Чтение мануала особо не раскрыло вопрос
Кластер выбран для надежности - довольно нагруженное веб приложение, с частыми insert / update, MyISAM регулярно рушится
C чего начать поиск неисправностей?
Неактивен
1. Сколько всего нод, какая у них конфигурация? Если всего две машины, то кластер не обеспечит надежность
2. Какая версия MySQL 5.0 или 5.1? Данные хранятся на диске или в памяти?
3. Что говорит explain на Ваши запросы?
Неактивен
Cardinality - известная бага http://bugs.mysql.com/bug.php?id=14243
Если EXPLAIN скажет, что индекс не использован, попробуйте добавить FORCE INDEX(имя_индекса) к запросу
Неактивен
1. Сколько всего нод,
2 ноды и 1 менеджмент сервер
какая у них конфигурация?
Хеon с 4мя гигами памяти
Если всего две машины, то кластер не обеспечит надежность
Три машины, как и требуется в документации
2. Какая версия MySQL 5.0 или 5.1?
Была 5.0, сейчас 5.1
Данные хранятся на диске или в памяти?
Странный вопрос, NDB всегда хранится в памяти
3. Что говорит explain на Ваши запросы?
Показывает, что индексы используются и все должно выполняться в считанные секунды.
Неактивен
schleicher написал:
Данные хранятся на диске или в памяти?
Странный вопрос, NDB всегда хранится в памяти
В 5.1 есть возможность хранить таблицы на диске.
schleicher написал:
3. Что говорит explain на Ваши запросы?
Показывает, что индексы используются и все должно выполняться в считанные секунды.
Попробуйте все-таки force index, если для ndb не работает статистика, то не факт, что работает правильно explain.
можете ли Вы упростить запросы и структуру таблиц так, чтобы они были как можно проще, но все равно тормозили, тогда можно будет поместить это на bugs.mysql.com
Неактивен
schleicher написал:
при выполнении среднего по сложности запроса (с участием 4 таблиц, все поля по которым осуществляется связь и выборка имеют индексы) время выполнения достигает 80 секунд, тот же запрос на той же базе в MyISAM укладывается в миллисекунды.
Структуру этих таблиц и индексов неплохо бы увидеть, а также их размеры.
Неактивен
Вот таблицы:
CREATE TABLE categories (
categories_id int(11) NOT NULL auto_increment,
categories_image varchar(64) default NULL,
parent_id int(11) NOT NULL default '0',
sort_order int(3) default NULL,
date_added datetime default NULL,
last_modified datetime default NULL,
login_id int(11) NOT NULL default '0',
PRIMARY KEY (categories_id)
) ENGINE=ndbcluster DEFAULT CHARSET=cp1251;
CREATE INDEX idx_login ON categories (login_id);
CREATE TABLE products (
products_id int(11) NOT NULL auto_increment,
products_quantity int(4) NOT NULL default '0',
products_model varchar(12) default NULL,
products_image varchar(64) default NULL,
products_price decimal(15,4) NOT NULL default '0.0000',
products_date_added datetime NOT NULL default '0000-00-00 00:00:00',
products_last_modified datetime default NULL,
products_date_available datetime default NULL,
products_weight decimal(5,2) NOT NULL default '0.00',
products_status int(11) NOT NULL default '0',
products_tax_class_id int(11) NOT NULL default '0',
manufacturers_id int(11) default NULL,
products_ordered int(11) NOT NULL default '0',
products_comp varchar(20) NOT NULL default '',
products_point varchar(20) NOT NULL default '',
products_countryt int(1) NOT NULL default '0',
products_country int(5) NOT NULL default '0',
products_type varchar(30) NOT NULL default '',
products_domains varchar(255) default NULL,
products_otype int(11) NOT NULL default '0',
PRIMARY KEY (products_id)
) ENGINE=ndbcluster DEFAULT CHARSET=cp1251;
CREATE INDEX idx_status ON products (products_status);
CREATE TABLE products_description (
products_id int(11) NOT NULL default 0,
language_id int(11) NOT NULL default 1,
products_name varchar(255) NOT NULL default '',
products_description text,
products_url varchar(255) default NULL,
products_viewed int(5) default 0
) ENGINE=ndbcluster DEFAULT CHARSET=cp1251;
CREATE INDEX idx_product ON products_description (products_id);
CREATE INDEX idx_lang_id ON products_description (language_id);
DROP TABLE IF EXISTS products_to_categories;
CREATE TABLE products_to_categories (
products_id int(11) NOT NULL default '0',
categories_id int(11) NOT NULL default '0',
id_ex int(14) NOT NULL default '0'
) ENGINE=ndbcluster DEFAULT CHARSET=cp1251;
CREATE INDEX idx_p2c_product ON products_to_categories (products_id);
CREATE INDEX idx_p2c_category ON products_to_categories (categories_id);
Данные по количеству записей:
categories 32,265 (8.1 MB)
products 69,728 (20.6 MB)
products_description 485,418 (165.3 MB)
products_to_categories 111,071 (11.0 MB)
тестовый запрос:
Showing rows 0 - 5 (6 total, Query took 47.7128 sec)
SQL-query:
SELECT p.products_id AS id, pd.products_name AS name, pd.products_description AS descr, p.products_price AS price, p.products_image AS image, p.manufacturers_id AS mid, p2c.id_ex
FROM products p, products_description pd , categories c, products_to_categories p2c
WHERE pd.products_id = p.products_id
AND p.products_status = 1
AND p2c.products_id = p.products_id
AND c.categories_id = p2c.categories_id
AND c.login_id = 196
AND pd.language_id =1
ORDER BY p.products_ordered
LIMIT 10
его EXPLAIN:
1 SIMPLE p ref PRIMARY,idx_status idx_status 4 const 10 Using where; Using filesort
1 SIMPLE pd ref idx_product,idx_lang_id idx_product 4 intway.p.products_id 1 Using where with pushed condition
1 SIMPLE p2c ref idx_p2c_product,idx_p2c_category idx_p2c_product 4 intway.pd.products_id 1 Using where
1 SIMPLE c eq_ref PRIMARY,idx_login PRIMARY 4 intway.p2c.categories_id 1 Using where
Неактивен
да, тот же самый запрос на той же самой базе в InnoDB занимает 0.0006 sec
Неактивен
Создал Вашу структуру таблиц, но без данных воспроизвести ситуацию не могу. Предполагаю, что медленно выполняется pushed condition. Попробуйте поменять порядок JOIN-ов, и указать SELECT STRAIGHT_JOIN, чтобы оптимизатор не менял порядок JOIN-ов самостоятельно.
Неактивен
И значение переменной engine_condition_pushdown какое?
Неактивен
Неплохо помогло FORCE INDEX ('idx_login') с таблицей categories
Значит ли это то, что ndbcluster более чувствителен к качеству запросов?
Неактивен
schleicher написал:
Неплохо помогло FORCE INDEX ('idx_login') с таблицей categories
Значит ли это то, что ndbcluster более чувствителен к качеству запросов?
Здесь несколько факторов
1. Оптимизатор в MySQL по архитектуре общий, и сейчас он сам может учесть не все факторы, важные для движка ndb. Возможны ошибки, так как механизм оптимизации сложных запросов не откатан.
2. Ошибки оптимизации обходятся дороже. Например, запрос SELECT * FROM table_name WHERE x>y*y; в innodb выполнится путем перебора всех записей на диске. В ndb необходимо будет еще передать все записи на API-ноду, и только на ней обработать. В mysql >5.0.3 дата-ноды могут выполнять простую арифметику, это называется "push down conditon", но это только при engine_condition_pushdown=1 и только для простых операций (функции mysql, такие как md5() или sin() на ноды не переносятся).
Неактивен