<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dw="https://www.dreamwidth.org">
  <id>tag:dreamwidth.org,2016-12-25:2612358</id>
  <title>crower</title>
  <subtitle>crower</subtitle>
  <author>
    <name>crower</name>
  </author>
  <link rel="alternate" type="text/html" href="https://crower.dreamwidth.org/"/>
  <link rel="self" type="text/xml" href="https://crower.dreamwidth.org/data/atom"/>
  <updated>2017-03-27T04:16:27Z</updated>
  <dw:journal username="crower" type="personal"/>
  <entry>
    <id>tag:dreamwidth.org,2016-12-25:2612358:109840</id>
    <link rel="alternate" type="text/html" href="https://crower.dreamwidth.org/109840.html"/>
    <link rel="self" type="text/xml" href="https://crower.dreamwidth.org/data/atom/?itemid=109840"/>
    <title>Where var IN (…)</title>
    <published>2017-03-27T04:16:27Z</published>
    <updated>2017-03-27T04:16:27Z</updated>
    <category term="sql"/>
    <dw:security>public</dw:security>
    <dw:reply-count>0</dw:reply-count>
    <content type="html">Знал я что &lt;strong&gt;where field in (&amp;hellip;)&lt;/strong&gt; &amp;mdash; довольно дорогая конструкция, но чтобы на столько!&lt;br /&gt;Иногда приходится её использовать в тех случаях, когда расходы на неё совсем небольшие, а методы обхода оказываются гораздо дороже.&lt;br /&gt;Была старая задача, которая генерировала сводку по нескольким таблицам. В таблицах &amp;mdash; результаты работы измерительных программ по изменению нагрузки. Ключевые параметры &amp;mdash; дата/время, период, объект измерения. Данные собираются по 5, 15, или часовым интервалам. И тут нужно нарисовать табличку: колонка - дата, строка - параметр. Диапазон дат &amp;mdash; до месяца, но не подряд, а выборочно. Вот тут-то и корячится &lt;strong&gt;where date in (date1, &amp;hellip;, dateN)&lt;/strong&gt;. Свинство в том, что поля date нет, а есть datetime, то есть timestamp. А значит нужно делать или date(datetime), или substr(datetime, 1, N) в тех случаях, когда группировка по другим критериям. А это тоже накладно. Потом ещё будет group by по этому полю. Но where вырастает в &lt;b&gt;date(datetime) in (…)&lt;/b&gt; и работает, соответственно, гораааздо дольше. Пока табличка была маленькая, всё работало довольно шустро. Но вот данных за год нападало уже на 23 миллиона и запрос стал выбираться несколько секунд. А это неприятно. Пришлось брать из загашников бубен. ;)&lt;br /&gt;Первым делом попытался ограничить область поиска дополнительным условием. Т.е. минимальная и максимальная даты определяют вилку, за пределами которой можно ничего не искать. &lt;br /&gt;Не помогло.&lt;br /&gt;Без особой надежды решил убрать &lt;b&gt;in (…)&lt;/b&gt; вообще, благо алгоритм обработки получаемых данных был построен так, что заполнял таблицу только нужными датами, а поправить нужно было только подсчёт итоговых значений, что делается одной строчкой.&lt;br /&gt;Запускаю — и удивляюсь. Вместо &lt;u&gt;нескольких&lt;/u&gt; секунд запрос стал выполняться доли секунды.&lt;br /&gt;И это при том, что из-за group by калькуляция в запросе вынуждена выполняться над лишними датами!&lt;br /&gt;Ладно, думаю. Может этот период просто незаполнен и пока ещё нечего считать? Делаю запрос за прошлый год и картина почти такая-же. Значит на самом деле 8*SUM+2AVG за 20 дней (по 288 измерений) выполняется гораздо быстрее, чем то же самое с &lt;b&gt;IN (date1..date20)&lt;/b&gt;.&lt;br /&gt;«&lt;i&gt;Вот что крест животворящий делает&lt;/i&gt;»©&lt;br /&gt;&lt;br /&gt;&lt;img src="https://www.dreamwidth.org/tools/commentcount?user=crower&amp;ditemid=109840" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/&gt; comments</content>
  </entry>
</feed>
