Производительность сравнения SQL с использованием подстроки против как с подстановочным знаком - PullRequest
6 голосов
/ 15 сентября 2011

Я работаю над условием соединения двух таблиц, в которых один из столбцов для сопоставления является объединением значений.Мне нужно присоединить columnA из таблицы A к первым 2 символам columnB из таблицы B.

Я разработал 2 различных оператора, чтобы справиться с этим, и я попытался проанализировать производительность каждого метода.

Метод 1:

ON tB.columnB   like  tA.columnA || '%'

Метод 2:

ON substr(tB.columnB,1,2) = tA.columnA

План выполнения запроса имеет намного меньше шагов с использованием метода 1 по сравнению с методом 2, однако онпохоже, что способ 2 выполняется гораздо быстрее.Кроме того, план выполнения показывает рекомендуемый индекс для метода 2, который может улучшить его производительность.

Я выполняю это на IBM iSeries, хотя в общем смысле мне было бы интересно узнать ответы, чтобы узнать больше об оптимизации SQL-запросов.,

Имеет ли смысл, что метод 2 будет выполняться быстрее?

Этот вопрос SO похож, но, похоже, никто не дал конкретных ответов на разницу в производительности этих подходов: Сравнение скорости T-SQL между LEFT () и оператором LIKE .

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

Ответы [ 4 ]

3 голосов
/ 06 мая 2014

Я запустил следующее в SQL Advisor в IBM Data Studio для одной из таблиц в моей базе данных DB2 LUW 10.1:

SELECT *
FROM PDM.DB30
WHERE DB30_SYSTEM_ID = 'XXX'
    AND DB30_VERSION_ID = 'YYY'
    AND SUBSTR(DB30_REL_TABLE_NM, 1, 4) = 'ZZZZ'

и

SELECT * 
FROM PDM.DB30 
WHERE DB30_SYSTEM_ID = 'XXX' 
    AND DB30_VERSION_ID = 'YYY' 
    AND DB30_REL_TABLE_NM LIKE 'ZZZZ%' 

У них обоих был один и тот же путь доступа, использующий один и тот же индекс, одну и ту же оценочную стоимость ввода-вывода и одну и ту же оценочную мощность, единственное отличие состоит в том, что оценочная общая стоимость ЦП для LIKE составила 178 343,75, а SUBSTR - 197 518,48 (~ 10% разница).

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

2 голосов
/ 15 сентября 2011

Да, метод 2 будет быстрее.Функция LIKE не так эффективна.

Чтобы сравнить производительность различных методов, попробуйте использовать Visual Explain.Вы найдете его в System i Navigator.Под системным подключением разверните базы данных, затем нажмите на свое имя RDB.В нижней правой панели вы можете нажать на опцию Run SQL Script.Введите в свой оператор SELECT и выберите пункт меню для Visual Explain или Run and Explain.Визуальное объяснение разделит план выполнения вашего заявления и покажет вам стоимость каждой части, рассчитанную по вашим таблицам с доступными индексами.

1 голос
/ 09 декабря 2015

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

Как всегда лучше в моем беге.

select count(*) from u_log where log_text like 'AUT%';
1 row(s) returned : 90ms taken

select count(*) from u_log where substr(log_text,1,3)='AUT';
1 row(s) returned : 493ms taken
0 голосов
/ 16 сентября 2011

Я нашел эту ссылку в справочнике IBM по производительности SQL. Похоже, что скалярная функция SUBSTR может быть оптимизирована в iSeries.

Если вы ищете первый символ и хотите использовать вместо него SQE CQE, вы можете использовать подстроку скалярной функции на левом знаке знака равенства. Если вам нужно искать дополнительные символы в В строке можно дополнительно использовать скалярную функцию POSSTR. От разделив предикат LIKE на несколько скалярных функций, вы можете повлиять на оптимизатор запросов для использования SQE.

http://publib -b.boulder.ibm.com / рефераты / sg246654.html? Open

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...