Witajcie,

potrzebuję roździelić zapytanie na części pierwsze. Najlepiej będzie pokazać na przykładnie:

STRING IN

[SQL] pobierz, plaintext 
SELECT 
    t1.whatever 
FROM 
    tabela1 t1 
    JOIN tabela2 t2 ON t1.id = t2.t1_id
WHERE
    t1.field1 = 'costam2'
    AND t2.field2 = 'costam1'
    AND t2.field18 = 'ugabuga'
[SQL] pobierz, plaintext 

A na wyjściu tablica

[PHP] pobierz, plaintext 
array(
    'tabela1' => array (
        'where' => array (
            'field1'
        ),
    ),
    'tabela2' => array (
        'where' => array (
            'field2', 'field18'
        ),
    ),
);
[PHP] pobierz, plaintext 

Potrzebne w celach optymalizacyjnych, badania szybkości wykonywania się zapytań, użytych indeksów, kolejności indeksów itp.
Czy istnieje jakiś inny sposób na rozdzielanie zapytań regxpkami ?

Znam ten temat... próbowałem to samemu ogarnąć od podstaw, miałem nawet jakieś sukcesy ale nie takie jakie chciałem. Potem przerabiałem i korzystałem z tego:

php-sql-parser

Ale to pozostawia wiele do życzenia...

Ja się poddałem z tym ogólnie. Trzymam kciuki i jakby Ci się udało coś fajnego stworzyć to daj znać

Dzięki Sephirus - będę próbował.
Byłoby idealnie jakby EXPLAIN wyświetlał dodatkową kolumne 'wheres' przy każdej tabeli...

Sephirus - co dokładnie by Cię interesowało? Co chciałęś osiągnąć za pomocą tej klasy?

Ogólnie chciałem zrobić skrypt, któremu na wejście podawałbyś jakieś konkretne zapytanie wyrwane z systemu/aplikacji.

Skrypt profilowałby to zapytanie, wykonywał je, sprawdzał wyniki i wyświetlał odpowiednie info o wydajności.

Dodatkowo analizowałby samo zapytanie pod kątem:
- poprawnych indeksów - użyte pola w WHERE, ON, GROUP BY, ORDER BY,
- użycia funkcji w wyżej wymienionych klauzulach, które to powodują ignorowanie indeksów,
- analizował LIKE,
- sprawdzał rozmiary tabel tymczasowych tworzonych przy joinach i wskazywał na przeniesienie warunków dotyczących joinowanej tabeli z WHERE do ON w celu ograniczenia wielkości tych tymczasowych tabel,
- itp.

Pokazywałby z tego raport i dodatkowo poprawione zapytanie, które mu podaliśmy a także aktualizacje struktury (DROPy, ALTERy, CREATEy itp) która poustawiała by indeksy itp.

Choć znam się na rzeczy i sam wiem jak powinno wyglądać optymalne zapytanie i mam pomysły jak zrobić profilowanie oraz podpowiadanie to padłem właśnie na parsowaniu samego zapytania (od razu wziąłem sobie dość obszerne by niczego nie pominąć i poległem )

Mozliwe by wówczas też było autonaprawianie struktury bazy przez skrypt. I tak musi on mieć dostęp do bazy by analizować tabele szukając indeksów itd. więc przy okazji by mogłobyć i to wykonywane.

EDIT: no właśnie i co bym chciał osiągnać? Skrypt/aplikację która podpięta pod naszą aplikację, automatycznie pokazałaby nam co poprawić, lub wskazała na co zwrócić uwagę.

Właściwie to chodzi mi o to samo z tym że ja tego tak obszernie nie planowałem.
Wstępnie chciałem zrobić coś co rozłoży zapytanie na czynniki (głównie część WHERE) i przeanalizuje indeksy w poszukiwaniu dziur, braków lub błędnej kolejności.
Skrypt miałby gromadzić takie dane w konkretnej tabeli dzięki czemu po pewnym okresie obserwacji możnaby oprogramować podpowianie - które tabele należało by przerobić (w sensie indeksów), które indeksy są nie używane lub bardzo żadko używane (bardzo pomogłoby dla tabel często insertowanych) i którym zapytaniom w kodzie należałoby pozamieniać warunki.

Explodowanie JOINów i analizowanie razem z GROUP ORDER itp. planowałem dla analisera 2.0.

Mam już pewne beta-sukcesy przy nadpisywaniu tej klasy - sądzę, że wkładając w to trochę czasu i pracy można stworzyć coś ciekawego.

Mam do przeanalizowania kilka baz a każda kilkadziesiąt lub więcej tabel (aplikacje SUGAR CRM) w kierunku indeksów i wydajności i mimo, że mam na to dość sporo czasu stwierdziłem, ze stworzenie odpowiedniej aplikacji będzie bardziej przyszłościowe.

Myślę, że jak pojawią się konkretne sukcesy po stronie explodowania SQLa udostępnie pracę (kod, jakąś baze) - co 2 głowy to nie jedna, może będziesz miał chotę się włączyć?

Pozdrawiam.

Bardzo chętnie o ile starczy mi czasu. Możesz to zawsze wrzucić na jakiegoś githuba, google code czy bitbucket a stamtąd już się coś dalej będzie robić Daj znać jak idzie ja w wolnej chwili postaram się jeszcze pomyśleć co mogło by to podpowiadać i jak analizować

Rozumiem. U mnie też różnie z czasem dlatego posuwa się to powoli.

To co przedstawiłem w pierwszym poście jest już zrobione.

A mógłbyś napisać, czego oczekiwałeś na wyjściu parsera SQL? (z jakimś przykładem - wejściowym SQLem i wyjściową tablicą)

Czy planowałeś mergować przeparsowany SQL z wynikiem EXPLAIN danego zapytania?

Robiłem to już dość dawno temu szczerze mówiąc i nie do końca pamiętam założonej struktury. Była ona zbliżona do Twojej lecz z wyróżnieniem że dana tabela jest "joinowana" itd.

Co do explain to do tego nie doszedłem przez sam parser Ale miałem zamiar użyć explain i profilowania (set profiling = 1 + SHOW PROFILES) aby wyświetlić dodatkowe dane i zaznaczyć to co jest do poprawki ewentualnej - niestety projekt padł w zarodku a teraz przez parę dni nie mam na to czasu po prostu :/