Diskuze: Zrychlení dotazů v mysql

Člen

Zobrazeno 17 zpráv z 17.
K personalizaci obsahu a reklam, poskytování funkcí sociálních médií a analýze naší návštěvnosti využíváme soubory cookie. Informace o tom, jak náš web používáte, sdílíme se svými partnery pro sociální média, inzerci a analýzy. Partneři tyto údaje mohou zkombinovat s dalšími informacemi, které jste jim poskytli nebo které získali v důsledku toho, že používáte jejich služby.
Používáme nezbytné cookies pro fungování webu a s tvým souhlasem také analytické a marketingové cookies.
Zajišťují základní funkce, bezpečnost a služby, které sis vyžádal. Nelze je vypnout.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| ITnetwork | ITnetwork | Provoz webu, relace, přihlášení a uložení nastavení cookies. | PHPSESSID, auth_token, sid, itn_consent_impression, __Host-itn_consent | Relace až 1 rok |
| Google Tag Manager | Správa značek a načítání měřicích nástrojů webu. | Žádné | Neukládá se | |
| Google Fonts | Načítání typografie webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google Hosted Libraries | Načítání potřebných knihoven a stylů webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google reCAPTCHA | Ochrana formulářů a webu před zneužitím. | _GRECAPTCHA, rc::a, rc::b, rc::c, rc::f | Relace až 180 dní | |
| YouTube | Přehrávání vloženého video obsahu. | localStorage, IndexedDB; cookies after playback interaction | Relace až trvalé úložiště | |
| Vimeo | Vimeo | Přehrávání vloženého video obsahu. | __cf_bm, _cfuvid, vuid, localStorage, IndexedDB | Relace až 2 roky |
| Facebook Login | Meta | Přihlášení pomocí účtu třetí strany. | Úložiště řízené poskytovatelem | Relace až 1 rok |
| GoPay | GoPay | Zpracování uživatelem vyžádané platby. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
Pomáhají nám porozumět používání webu a zlepšovat ho.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Analytics 4 | Měření návštěvnosti a používání webu. | _ga, _ga_* | Až 2 roky | |
| Microsoft Clarity | Microsoft | Měření návštěvnosti a používání webu. | _clck, _clsk, _cltk | Relace až 1 rok |
Slouží k měření kampaní, personalizaci reklamy a marketingové komunikaci.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Ads | Měření kampaní, reklama a remarketing. | _gcl_au, _gcl_ls | Relace až 90 dní | |
| Meta Pixel | Meta | Měření kampaní, reklama a remarketing. | _fbp, _fbc, localStorage | Až 90 dní |
| Sklik | Seznam.cz | Měření kampaní, reklama a remarketing. | retargeting, sid, szn:* | Relace až trvalé úložiště |
| LinkedIn Insight | Měření kampaní, reklama a remarketing. | bcookie, li_gc, lidc, __cf_bm | Relace až 1 rok | |
| Ecomail | Ecomail.cz | Měření kampaní, reklama a remarketing. | ecmid, Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
| Atribuce kampaní ITnetwork | ITnetwork | Přiřazení návštěvy a objednávky ke kampani. | campaign_clid[*], user_session_context | Až 1 rok |


Zkus na ten daný sloupec aplikovat index. Nic jiného mě nenapadá...
Obávám se, že pouhé přidání indexu vůbec nepomůže. Index na stringových sloupcích se (pokud se nepletu) aplikuje na x znaků zleva, čili pokud budeš mit nevhodně sestavenej ten dotaz (like umístěné nevhodně), je celej index k ničemu.
napiš jak ten dotaz vypadá celej, jestli je to jen hledání v jedné tabulce, nebo jestli se tam neco joinuje... takhle můžeme jen hádat
index nejde použít. Pomalý dotaz, který řeším je v tom, že prochází LIKE %neco% pole, které je typu TEXT.
SELECT * FROM tabulka WHERE info LIKE (%neco%)
Žádný složitý dotaz to není, ale protože potřebuji prohledávat pole info v DB fulltextově, tak musím použít toto. Změnit typ na VARCHAR bohužel nelze, resp. nic mi nepomůže, protože i když jsem to zkusmo změnil a měl tam méně informací, tak se to nezrychlilo tolik, aby to mělo smysl měnit a přišel tak o část dat, která tam jsou.
Proto hledám nějaký vhodný způsob, aby se dotaz provedl rychleji.
Ty texty které prohledáváš mají něco společného, nebo jde o různé texty? Ptám se kvůli tomu jestli by ty texty nešly nějakým způsobem sdružit do nějakých skupin (rozuměj něco jako číselník textů ...).
co je to za DB ? MSSQL, MySQL, PostgreSQL, ORACLE ? nebo něco jiného ?
Nazev topicu je Zrychlení dotazů v mysql, tak ze predpokladam ze MySQL ...
Ano, mysql. Jde mi o zrychlení dotazu. Použít jiné hledání bohužel nemůžu vzhledem k tomu, že potřebuji fulltext. Hledám tedy zda nějak zlepšit dotaz nebo nastavení mysql serveru.
Ahoj, tady (https://makandracards.com/…-text-search) jsou poměrně
pěkně popsané dostupné metodiky pro vyhledávání nad texty v MySQL a
nějaký ten orientační benchmark test k tomu. Stačilo jenom trochu Googlit,
ale doufám, že to pomůže. 
Však googlim jako pominutý. Nicméně tady porovnávají dva dotazy a ten druhý pro mě nelze použít, protože to není fulltext, který potřebuji. Já potřebuji vyhledat i uprostřed slov a to umí jen LIKE nebo se mýlím?
Tak v první řadě, tohle jsou jediné dva standardní způsoby, jak v rámci MySQL hledat v textu a jak je vidět z toho testu, LIKE je v porovnání s FULLTEXT opravdu pomalý. A žádný index Ti nepomůže, jak už tady bylo řečeno.
FULLTEXT umí vyhledávat slova v textu, uprostřed slova ne viz. https://dev.mysql.com/…boolean.html
Dle mého názoru Ti za Tvých okolností tak nepomůže žádná optimalizace databázového vyhledání, ale měl by jsi spíš přemýšlet o předzpracování a optimalizaci těch dat samotných.
Popřípadě nad MySQL postavit nějakou další technologii jako ElasticSearch a používat ji pokud to jde.
To mě taky napadlo, případně úplně změnit databázový engine, ale
pokud jsem to dobře pochopil, oni mají prostě MySQL někde na webhostingu,
takže to asi jen tak nepůjde. 
Však já jsem se ani neptal na to, zda jsou jiné způsoby, ale spíše na, jestli je možné nějak vytunit DB, nechci kecat do práce hostingu, ale pokud by tam bylo nastaveno něco špatně, tak bych byl rád, aby nám to nastavili lépe.
Na ten engine se podívám.
Bohužel data jsou strukturována tak, že není možné je z toho hledání vyhodit. V podstatě se tu bavíme o rozdílu ve 100-200 ms, což není zase taková katastrofa.
Pak mně ještě napadla otázka. Jak nejlépe tedy navrhnout takto dlouhé texty 65535 znaků.
Je lepší, že bude prohledávat např. 10 varchar polí nebo je to jedno?
Zobrazeno 17 zpráv z 17.