MySQL запрос, проблема с использованием индексов!

Буду рад любым пинкам в правильном направлении.

postgresql.

Буду рад любым пинкам в правильном направлении.

left join

А вообще

show create table `table1`;

и

show create table `table2`;

В студию

А то нихера не понятно на каких полях у тебя индексы. Мож ты на поле сортировки его поставил, а на поля по которым связываешь - нет.

postgresql

А вот и любители собственное невежество за косяки ПО выдавать.

А если через подзапрос сделать, какой из вариантов будет дольше?

CREATE TABLE `table1` (
  `l_id` int(11) NOT NULL AUTO_INCREMENT,
  `a_id` int(11) NOT NULL,
  `l_name` varchar(256) NOT NULL,
  PRIMARY KEY (`l_id`),
  KEY `a_id` (`a_id`),
  KEY `l_name` (`l_name`)
) ENGINE=MyISAM AUTO_INCREMENT=1222617 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC

CREATE TABLE `table2` (
  `a_id` int(11) NOT NULL AUTO_INCREMENT,
  `g_id` int(11) NOT NULL,
  `y_id` int(11) NOT NULL,
  PRIMARY KEY (`a_id`)
) ENGINE=MyISAM AUTO_INCREMENT=100001 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC

Дело в том, что данных много - table1 более 1 млн записей, table2 - 100000 записей.

Через подзапрос - временная таблица долго создается. Чуть чуть быстрее, но это уже и память кушает.

любопытно, а чего g_id не индекс? ты ж по нему выбираешь..

1. Добавь индекс для `g_id`, у тебя же это поле в условии стоит

2. Давай сделаем с твоим запросом вот что

SELECT
   SQL_NO_CACHE #для чистоты эксперемента
   `al`.`i_id` as `id`,
   `al`.`l_name` as `name`,
   `a`.`a_id` as `a_id`
FROM 
   `table1` as `al`
      LEFT JOIN
   `table2` as `a`
      ON `a`.`a_id`=`al`.`a_id`
WHERE
   `a`.`g_id` IN (1)
ORDER BY 
   a.l_name ASC
limit 1000 , 30;

То есть

а) Свяжем таблицы через JOIN

б) Ограничим число выбираемых полей

Мда... школоло. Иди почитай сначала про SQL.

Поставил. Тот же запрос который выполняется 1 сек. выполняться стал 1 min 3.64 sec

Поставил. Тот же запрос который выполняется 1 сек. выполняться стал 1 min 3.64 sec

гм.. гм.. а ты не юзаешь там force index? если юзаешь, убери.

ну и эксплейн в студию если совет разина не поможет.

2. Запрос выполнил. Запрос выполняется ровно столько, сколько и мой запрос. (я уже задавал вопрос на другом сайте, мне дали подобный запрос в ответ)

1. Как только я добавил индекс, Запрос выполнился за 0.05 сек. Но как только я в условие IN добавил десяток циферок - запрос стал выполняться больше секунды. Проблема стала «с точностью до наоборот» :)

б. Запрос , таблица, имена полей - тестовые. Поэтому я использую «*» вместо перечисления. Перечисление никакого ускорения не даст, т.к. проблема совсем в другом.

EXPLAIN запроса который выполняется 1 сек c LEFT JOIN

EXPLAIN запроса который выполняется 1 сек БЕЗ LEFT JOIN

на 50% уверен, что ты даже не понял суть проблемы, а на 99.9% уверен что тебе никогда не решить такой запрос.

на 50% уверен, что ты даже не понял суть проблемы, а на 99.9% уверен что тебе никогда не решить такой запрос.

Я щаслив за тебя.

не используй смещение. limit 1000 , 30;

Очень интересное решение.. Но мне нужен limit :)

что-то мне кажется что во второй таблице нужно не два отдельных индекса а один составной

делал... причем составной так же работает как и 2 отдельных индекса

лимит можно использовать но смещение на больших таблицах никогда, посмотри в плане запроса как мускул его обрабатывает - чтоб найти смещение мускуль пройдется по всем записям игнорируя индекс (а как по другому?), поэтому если будешь брать записи с 100000 20 штук то физически мускуль отгребет 100000+20 записей. http://www.scribd.com/doc/14683263/Efficient-Pagination-Using-MySQL

Поидее ваш ответ самый правильный. Спасибо

А вот и любители собственное невежество за косяки ПО выдавать.

PHP и mysql — братья навек, понимаю.

как же он без смещения.. жить то надо как-то..

Mysql обычно делает слияние довольно индексов довольно в тему.. так что вряд ли поможет..

хорошие советы, спасибо

Братья навек - это postgre и пионЭры

После ANALYZE и постгресовского планировщика ковыряться в мускульных эксплейнах захотят люди только определенного склада ума.

postgres the best. для холивара создавайте отдельный тред.

На это сообщение отвечать не нужно.

Под эту задачу неплохо сфинкс подходит - http://habrahabr.ru/blogs/webdev/40443/ Еще можно заюзать какой-то хандлерсокет или мемкашединнодб интерфейс, ну и перейти на иннодб - муисам сакс.

Мне ченжлог новой постгри понравился)

Почитай еще http://www.mysqlperformanceblog.com/