Все технические форумы на одном сайте Удобный поиск информации с популярных форумов в одном месте
Вопрос: Первое поле в составном индексе

Если запрос WHERE a=1 AND b=2
С a=1 14 тыс. записей
С b=2 3 тыс. записей
То в составном индексе b надо вперёд ставить и делать запрос b=2 AND a=1?
Ответ:
MasterZiv
более селективное поле надо ставить раньше, если нет других соображений.
Имхо как раз если других соображений нет, то глубоко пофиг. Бо поиск индексный ведётся сразу по всему выражению, а не "сперва по префиксу, потом по остальной части".
А случаи, когда в условиях, приводящих к использованию индекса, присутствует только одно из двух плей - это как раз "другие соображения".
Вопрос: Проблема с составным индексом

Есть таблица, в которой штук 20 полей (одно из них - ключевое). Делаю составной индекс из 10 (максимально возможное количество) полей (ключевое в них не входит, разумеется), в свойствах индекса указываю "Уникальный индекс - Да". Для проверки срабатывания уникальности копирую одну из строк набора данных и вставляю её и ... она, блин, добавляется без проблем. Как так? Добавляется строка полностью идентичная (кроме поля ключа) уже имеющейся, типа уникальный индекс этому добавлению ничуть не мешает. В чем засада?
Ответ: 6076, да, есть. Видимо действительно из за них проблема. Единственный выход, как понимаю, обеспечить отсутствие null путем проверки и подстановки какого то заполняющего значения в эти поля? Мне надо при массовой вставке новых строк запросом на добавление исключить полностью одинаковые строки. Как то по другому, без использования индекса, это как то сложно получается...
Вопрос: Простой или составной индекс

Есть таблица вида:

CREATE TABLE IF NOT EXISTS `GraphicsImages` (
  `GraphicsImagesID` int(11) NOT NULL AUTO_INCREMENT,
  `ExtTable` enum('GoodsGen','GoodsEntGen','GoodsGroups','Vendors','VendorsCountries') NOT NULL COMMENT 'Таблица, которой принадлежит изображение',
  `ExtTableID` int(11) DEFAULT NULL COMMENT 'ID элемента в таблице',
  `DefaultImage` tinyint(1) NOT NULL COMMENT 'Основное изображение, если > 0',
  `GraphicsImagesTypesID` tinyint(4) NOT NULL COMMENT 'Идентрификатор типа изображения',
  `Description` text NOT NULL COMMENT 'Описание изображения',
  `Image` varchar(255) NOT NULL COMMENT 'Путь к изображению',
  `ImageFormat` enum('','jpeg','png','gif') NOT NULL COMMENT 'Формат изображения',
  `Width` smallint(5) unsigned DEFAULT NULL COMMENT 'Ширина изображения (пикселей)',
  `Height` smallint(5) unsigned DEFAULT NULL COMMENT 'Высота изображения (пикселей)',
  PRIMARY KEY (`GraphicsImagesID`),
  KEY `ExtTableID` (`ExtTableID`)
) ENGINE=MyISAM;


В ExtTable содержится название таблицы, к которой относится изображение, а в ExtTableID - ID первичного ключа в указанной таблице.

С учетом того, что ExtTable это ENUM с 5 значениями, стоит ли делать составной индекс на 2 колонки ExtTable, ExtTableID или это бессмысленно и эффективнее будет работать индекс по одной колонке ExtTableID?
Ответ:
Int_20h
miksoft,

COUNT(*)COUNT(DISTINCT ExtTableID)COUNT(DISTINCT ExtTableID ExtTable)
453221984396


Пока так. В дальнейшем количество строк будет расти примерно в таких же пропорциях.

Есть еще таблица с подобной структурой. В ней показатели следующие:

COUNT(*)COUNT(DISTINCT ExtTableID) COUNT(DISTINCT ExtTableID ExtTable)
576913791608
Для этого случая вполне достаточно индекса по одному полю ExtTableID.
Вопрос: Можно ли обойтись без составного индекса?

Много текста, налейте чаю ))

Отдельные запросы по members и d_p выполняются быстро (первые 2), но стоит их хоть как-то объединить и всё печально. Да можно добавить составной индекс members + d_p и я добавил его (последний запрос) результат хороший, но у меня около 10 запросов где используется members + ещё какое-то поле если на них все создавать по составному индексу то это накладно по месту не говоря уж о том что они будут намного больше доступной оперативной памяти.

0.0051 сек. (8800 строк)
SELECT SQL_NO_CACHE `id` FROM `table` WHERE members > 100000


0.0054 сек.
SELECT SQL_NO_CACHE `id`,`d_p` FROM `table` WHERE `d_p` != 999.99 ORDER BY `d_p` DESC LIMIT 20


1.18 сек. используется индекс d_p
SELECT SQL_NO_CACHE `id`,`d_p` FROM `table` WHERE `d_p` != 999.99 AND members > 100000 ORDER BY `d_p` DESC LIMIT 20


Заменим принудительно индекс с d_p на members
2.88 сек.
SELECT SQL_NO_CACHE `id`,`d_p` FROM `table` USE INDEX (members) WHERE `d_p` != 999.99 AND members > 100000 ORDER BY `d_p` DESC LIMIT 20


Используем подзапрос:
2.94 сек.
SELECT SQL_NO_CACHE `id`,`d_p` FROM `table` WHERE `d_p` != 999.99 AND `group_id` IN (SELECT `group_id` FROM `vkgroups` WHERE members > 100000) ORDER BY `d_p` DESC LIMIT 20


Создадим, применим новый составной индекс
0.062
SELECT SQL_NO_CACHE `id`,`d_p` FROM `table` USE INDEX (members_d_p) WHERE members > 100000 AND `d_p` != 999.99 ORDER BY `d_p` DESC LIMIT 20
Ответ:
автор
INFORMATION_SCHEMA.TABLES
Rows, Avg_row_length и Data_length

Извините я чё-то не догнал, там дофига данных непонятно совершенно какие для какой таблицы ))
Вопрос: Составной индекс в MySQL и WHERE IN ()

Здравствуйте. Помогите понять.

Есть таблица tab: id(int) + col1(int) + col2(int) + col3(int) + col4(int)

есть составной индекс COL :col1+col2+col3+col4

и вот такой запрос:

SELECT *
FROM tab
WHERE
col1 IN (1,6,9) AND
col2=54 AND
col3 IN (0,1) AND
col4=5

Правильно ли я понимаю, что здесь полностью используется индекс COL ? Несмотря на IN mysql просто еще раз обходит по индексу.

EXPLAIN вроде говорит что это так - Using index conditionи показывает точно число строк.

А вот если б было:

SELECT *
FROM tab
WHERE
col1>0 AND
col2=54 AND
col3 IN (0,1) AND
col4=5

то индекс бы не использовался после col1.

Так? Я всё правильно понимаю?
Ответ: MasterZiv

Спасибо Вам!
Вопрос: Скорость SELECT-запроса и составной индекс по INTEGER и TIMESTAMP

Имеется таблица "Транзакции", в которой поля "ID карты" (CARD_ID INTEGER) и "время транзакции" (TRANTIME TIMESTAMP) входят в составной индекс, примерно так:
CREATE INDEX TRAN_IDX1 ON TRAN (CARD_ID, TRANTIME);


за период с 1.01.2017 по 9.08.2017 в таблице TRAN накоплено 367 тыс. транзакций по 11 тыс. картам, однако по карте с CARD_ID=100 всего лишь 2 транзакции.

Если я пишу запрос:

SELECT * FROM TRAN WHERE CARD_ID=100 AND 
TRANTIME BETWEEN '2017-01-01' AND '2017-08-09'


то он возвращает 2 транзакции, причем запрос выполняется в среднем 46 мс.
При этом IBExpert показывает:
Fetches from cache = 1 867



Если в запросе интервал времени небольшой (транзакции были 25 и 29 марта):
SELECT * FROM TRAN WHERE CARD_ID=100 AND 
TRANTIME BETWEEN '2017-03-25' and '2017-03-30'


то запрос выполняется за 0 мс (редко 16 мс).
При этом IBExpert показывает:
Fetches from cache = 78


Разница - десятки раз!

Для меня это оказалось сюрпризом, поскольку я считал, что указание в индексе первым полем CARD_ID сужает интервал поиска и транзакции по другим картам не влияют на скорость выборки по конкретной карте, а по факту выходит, что влияют, и очень здорово.

Данная проблема снижения производительности свойственна только Firebird или это общая проблема, свойственная всем СУБД. В версиях Firebird 2.5 и 3.0 ситуация та же?

P.S. Версия Firebird 2.1.5 (SuperServer).
Ответ:
Что за привычка утаивать планы, телепатию нам прокачивать?


Сорри!

+1 тебе к телепатии :)
Вопрос: Как создать уникальный составной индекс, который может содержать null значение

Приветствую!
Вопрос: как запретить на уровне БД возможность вставки одинаковый записей.
Собственно сама таблица:
CREATE TABLE "public"."test" (
    "name" text COLLATE "default" NOT NULL,
    "parent_id" int4,
    "id" SERIAL PRIMARY KEY
)
WITH (OIDS=FALSE);
ALTER TABLE "public"."test" OWNER TO "postgres";

CREATE INDEX "test_name" ON "public"."test" USING btree ("name");
CREATE UNIQUE INDEX "test_name1" ON "public"."test" USING btree ("name", "parent_id") WHERE parent_id IS NOT NULL;
CREATE UNIQUE INDEX "test_name2" ON "public"."test" USING btree ("name", "parent_id") WHERE parent_id IS NULL;

Выше описанная таблица позволяет добавлять одинаковые записи:
INSERT INTO test (name) VALUES ('test');
INSERT INTO test (name) VALUES ('test');

Хотя если я правильно понимаю, во время попытки добавления второй раз записи должен был сработать индекс test_name2, но он почему-то не сработал.
И появляется главный и самый важный вопрос: почему не сработал индекс test_name2 и как сделать так что бы сработал?)
Ответ: Maxim Boguk,

Спасибо, то что нужно)
Вопрос: Порядок полей в составном ключе

Есть таблица с полями id (primary key, int), category_id (int), group_id (int).
Есть составной индекс с двух полей: category_id + group_id (unique).
Есть запрос вида SELECT ... WHERE group_id = 1 AND category_id = 1
EXPLAIN говорит, что индекс при выборке используется.

Внимание, вопрос :D
При двух полях в составном индексе есть ли разница в последовательности полей при запросе или mysql при выборке упорядочнит поля согласно имеющемуся индексу?
Ответ:
NMFES
При двух полях в составном индексе есть ли разница в последовательности полей при запросе или mysql при выборке упорядочнит поля согласно имеющемуся индексу?


при нескольких в индексе разница есть в порядке их следования в индексе, но для именно данного запроса этот порядок не важен.
Вопрос: Порядок расположения колонок составного индекса

Задача: создать индекс из нескольких двух колонок таблицы.
Вопрос: как неинтуитивным путем понять в каком порядке их расположить?
Ответ: kaldorey,

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

--Eugene--
Но рядом будет составной локальный индекс, включающий как ключи секционирования, так и первичного ключа.



Первичный ключ судя по предыдущему посту не составной. Можете привести пример,
где необходим такой составной локальный индекс.
Вопрос: Как узнать какие запросы используют выбранный индекс(ы)?

Есть задача почистить индексы.
Однако судя по статистики по какой-то причине совершенно абсурдные составные индексы используются по непонятно каким запросам и неясно для чего нужны. Вариант с удалением индекса и просмотром "что будет" не предлагать - система чувствительна к любому "чиху".
Ответ:
altair86
Есть задача почистить индексы.
Однако судя по статистики по какой-то причине совершенно абсурдные составные индексы используются по непонятно каким запросам и неясно для чего нужны. Вариант с удалением индекса и просмотром "что будет" не предлагать - система чувствительна к любому "чиху".


Никак особо. Включить полный лог и далее explain автоматический по всем запросам запустить.
Ну и проанализировать очевидно избыточные индексы вида on (a) когда уже есть on (a, b)

Ну а вообще для таких экспериментов должен быть честный тестовый стенд где можно эмулировать нагрузку и экспериментировать (если уж
автор
система чувствительна к любому "чиху"
).

--
Maxim Boguk