Det här verkar vara en bugg i MySQL som jag har skickat in en rapport om . Jag har begränsat det till följande testfall, som man skulle förvänta sig att returnera en enda post (men det gör det inte):
CREATE TABLE t (x INT NULL); -- table with nullable column
INSERT INTO t VALUES (0); -- but non null data
SELECT a.x -- select our nullable column
FROM t a, (SELECT NULL) b -- joining it with anything at all
WHERE EXISTS ( -- but filter on a subquery
SELECT *
FROM (SELECT NULL) c -- doesn't really matter what
HAVING a.x IS NOT NULL -- provided there is some correlated condition
-- on our nullable column in the HAVING clause
)
ORDER BY RAND() -- then perform a filesort on the outer query
Se den på sqlfiddle .
I ditt fall kan du göra ett antal saker för att fixa detta:
-
Undvik den korrelerade underfrågan genom att skriva om som en join:
SELECT * FROM people AS p LEFT JOIN (people_stages AS s NATURAL JOIN ( SELECT person_id, MAX(created) created FROM people_stages GROUP BY person_id ) t) ON s.person_id = p.id ORDER BY p.last_name
-
Om du vill behålla den korrelerade underfrågan (som i allmänhet kan ge dålig prestanda men ofta är lättare att förstå), använd
WHERE
istället förHAVING
:SELECT * FROM people AS p LEFT JOIN people_stages AS s ON s.person_id = p.id WHERE s.created = ( SELECT MAX(created) FROM people_stages WHERE person_id = s.person_id ) ORDER BY p.last_name
-
Om du inte kan ändra frågan bör du märka att du gör
people_stages.person_id
kolumn som inte är nullbar kommer att komma runt problemet:ALTER TABLE people_stages MODIFY person_id BIGINT UNSIGNED NOT NULL
Det verkar som att ett index på den kolumnen (vilket skulle krävas för att påverka en främmande nyckel) också kan hjälpa:
ALTER TABLE people_stages ADD FOREIGN KEY (person_id) REFERENCES people (id)
-
Alternativt kan man ta bort
people_stages.person_id
från urvalslistan, eller justera datamodellen/indexeringen/frågestrategin för att undvika en filsortering (kanske inte praktiskt i det här fallet, men jag nämner dem här för fullständighetens skull).