Nos közben megszületett a megoldás:
Mint az oly sokszor most is bebizonyosodott, hogy amit egy programozó elront azt egy rendszergazda nem valószínű, hogy tudja kompenzálni. (Meg az is, hogy ha kakából építesz várat a decemberi hidegben, az tavasszal rád fog dőlni)
Először is a maatkit nyújtotta eszközök nagyszerűek ahhoz, hogy megtaláld egy sql alapú alkalmazás gyenge pontjait.
A my.cnf -ben beállítottam, hogy azok a lekérdezések amelyek 2másdpercnél hosszabb ideig futnak, vagy nem használnak indexeket kerüljenek be a slow query log -ba:
# Here you can see queries with especially long duration
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2
log-queries-not-using-indexes
Ezt így hagytam egy 24 órán keresztül. Az összegyűlt logot azután az mk-query-digest -nek adtam oda:
mk-query-digest mysql-slow.log > maatkit.mk-query-digest.out
Az eredményül kapott statisztikából kiválogattam a query -ket és ezeket az mk-query-profiler -el tovább elemeztem
mk-query-profiler --database hiper_optimise -umaatkit -pAo0lkuseZ91 -h localhost --tab hiper_test2.sql > mk-query-profiler-report.csv
Ez továgg árnyalja a képet és ki, azáltal, hogy eredményez egy táblázatot amelyben látható, melyík lekérdezés hány sort és mekkora adatmennyiséget érint.
A lekérdezések működésének elemzésére ezután az EXPLAIN -t lehet használni. Ha sokat látod a "Using filesort" -ot az jót nem jelent, mivel ilyenkor temp file -t csinál a mysql.
Partícionálás:
Az látszik, hogy ez még nem tökéletes a mysql -ben. Még nem létező id -re nem lehet partíciót definiálni. Ha nem integer az id akkor lehet/kell a HASH partícionálást használni. A partícionálással 5-7% futásidőt lehet spórolni (optimálisabb query-kel gondolom többet)
Köszönöm mindenkinek a segítséget, ha esetleg valamit nem írtam le, kérdezzetek nyugottan!
----
올드보이
http://molnaristvan.eu/