Mam następujące zapytanie, które działa w 16ms - 30ms.

<code><cfquery name="local.test1" datasource="imagecdn">
    SELECT hash FROM jobs WHERE hash in(
        'EBDA95630915EB80709C69089315399B',
        '3617B8E6CF0C62ECBD3C48DDF8585466',
        'D519A38F09FDA868A2FEF1C55C9FEE76',
        '135F94C3774F7719CFF8FF3A275D2D05',
        'D58FAE69C559273D8427673A08193789',
        '2BD7276F209768F2FCA6635659D7922A',
        'B1E3CFBFCCFF6F5B48A849A050E6D424',
        '2288F5B8A797F5302E8CA24323617236',
        '8951883E36B5D38A4643DFAA0396BF13',
        '839210BD564E30BE1355D1A6D4EF7081',
        'ED4A2CB0C28B608C29576819CF7BE19B',
        'CB26925A4874945B810707D5FF0B91F2',
        '33B2FC229F0CC797A02AD163CDBA0875',
        '624986E7547DBAC0F47B3005CFDE0A16',
        '6F692C289BD805CEE41EF59F83F16F4D',
        '8551F0033C617BD9EADAAD6CEC4B3E9E',
        '94C3C0A74C2DE085FF9F1BBF928821A4',
        '28DC1A9D2A69C2EDF5E6C0E6368A0B3C'
    )
</cfquery>
</code>

Jeśli wykonam to samo zapytanie, ale użyję cfqueryparam, działa ono w 500ms - 2000ms.

<code><cfset local.hashes = "[list of the same ids as above]">
<cfquery name="local.test2" datasource="imagecdn">
    SELECT hash FROM jobs WHERE hash in(
        <cfqueryparam cfsqltype="cf_sql_varchar" value="#local.hashes#" list="yes">
    )
</cfquery>
</code>

Tabela ma około 60 000 wierszy. Kolumna „hash” to varchar (50) i ma unikalny indeks nieklastrowany, ale nie jest kluczem podstawowym. Serwer DB to MSSQL 2008. Na serwerze WWW działa najnowsza wersja CF9.

Jakiś pomysł, dlaczego cfqueryparam powoduje, że wydajność się bombarduje? Zachowuje się w ten sposób za każdym razem, niezależnie od tego, ile razy odświeżam stronę. Jeśli sparuję listę tylko z 2 lub 3 hashami, to nadal działa słabo na poziomie 150-200ms. Gdy wyeliminuję cfqueryparam, wydajność jest zgodna z oczekiwaniami. W tej sytuacji istnieje możliwość iniekcji SQL, a więc użycie cfqueryparam z pewnością byłoby lepsze, ale znalezienie 2 rekordów z kolumny indeksowanej nie powinno zająć 100 ms.

Edytuje:

Używamy skrótów generowanych przezhash() nie UUIDS ani GUIDS. Hash jest generowany przez ahash(SerializeJSON({ struct })) który zawiera plan zestawu operacji do wykonania na obrazie. Celem tego jest to, że pozwala nam poznać przed wstawieniem i przed zapytaniem dokładny unikalny identyfikator dla tej struktury. Te skróty działają jako „indeks” struktur, które zostały już zapisane w DB. W dodatku z hashami ta sama struktura będzie mieszała się do tego samego wyniku, co nie jest prawdą dla UUIDS i GUIDS.

Zapytanie jest wykonywane na 5 różnych serwerach CF9 i wszystkie wykazują to samo zachowanie. Dla mnie to wyklucza pomysł, że CF9 coś buforuje. Wszystkie serwery łączą się z dokładnie tą samą bazą danych, więc jeśli wystąpiłoby buforowanie, musiałby to być poziom bazy danych.