Varning för NOT-operatorn i MySQL med index

På senare tid har jag ibland använt NOT-operatorn ! i MySQL. T.ex. för att hämta alla registreringar som ännu ej processats:

SELECT * FROM registrations WHERE !processed;

Fältet processed i det här fallet är av typen TINYINT(1) (BOOLEAN).

Idag upptäckte jag till min stora förvåning att om jag lägger ett index på processed så har det ingen som helst effekt om jag använder ! eller NOT för att hitta raderna.

mysql> DESCRIBE SELECT * FROM registrations WHERE !processed;
+------+---------------+------+---------+------+--------+-------------+
| type | possible_keys | key  | key_len | ref  | rows   | Extra       |
+------+---------------+------+---------+------+--------+-------------+
| ALL  | NULL          | NULL | NULL    | NULL | 578614 | Using where |
+------+---------------+------+---------+------+--------+-------------+

Om jag däremot gör en helt vanlig jämförelse med 0 eller FALSE (som egentligen borde vara samma sak) så funkar det bra:

mysql> DESCRIBE SELECT * FROM registrations WHERE processed=FALSE;
+------+----------------+----------------+---------+-------+------+-------+
| type | possible_keys  | key            | key_len | ref   | rows | Extra |
+------+----------------+----------------+---------+-------+------+-------+
| ref  | processedindex | processedindex | 1       | const |    1 |       |
+------+----------------+----------------+---------+-------+------+-------+

I den här tabellen med nästan 600 000 rader tog queryn med ! 0.60 sekunder medan den som använde indexet tog 0.00.

Så kom ihåg! Använd inte "!", "NOT", "IS FALSE" eller liknande utan gör istället jämförelser med =. Även om de logiskt ger samma resultat.

Om någon vet varför det är på detta sätt så får ni gärna skriva en kommentar. Har sökt lite men inte hittat någon information om detta.

Styr webbläsaren med din iPhones gyroskop

Mika Tuupola har gjort ett inspirerande experiment som blandar flera av de senaste och hetaste teknikerna. Han får en HTML5-logga som visas i webbläsaren på hans dator att rotera med hjälp av sin iPhones gyroskop.



Gyroskopet får han tillgång till med iPhones DeviceOrientation API. Kommunikationen mellan webbläsaren och iPhonen sker över en socketanslutning som skapats med WebSocket som är en del av HTML5. Rotationen av loggan görs med 3D Transformationer i CSS3 (endast webkit än så länge).

Testa själv:
Öppna denna länk i safari på din dator
Öppna denna länk i din iPhone med iOS 4.2 eller högre

Läs Mika Tuupola eget blogginlägg om detta.

Radera aldrig data!

Flickr är en av några få webbtjänster som jag faktiskt betalar för. Jag tycker flickr är snyggt, enkelt att använda och framförallt har det känts tryggt att ha sina fotografier (som kanske är det värdefullaste man har) lagrade i molnet och inte på någon egen hårddisk som kan krascha när som helst. Idag slutade det dock kännas tryggt.

Flickr har råkat radera en betalande flickr-användares konto när de skulle radera någon helt annan som hade laddat upp copyright-skyddat material. Det är ungefär 4000 bilder som dessutom var flitigt inlänkade på andra sajter som har försvunnit. Flickr erbjöd den drabbade kunden 4 års gratis pro-medlemskap som ersättning. Mer om detta finns att läsa hos Techcrunch.

Några saker som man (framförallt flickr) kan lära sig av detta:

1. Det ska aldrig gå att radera information
En webbtjänst bör aldrig innehålla en möjlighet att på riktigt radera information. Inte i admin-gränssnitt, ingenstanns. Man kan ha ett system för att markera saker som raderade så att de döljs för användarna men att på riktigt ta bort informationen finns det absolut ingen anledning till, speciellt inte när lagringsutrymme idag i princip är gratis.

Jag brukar inte ens ge mina mysql-användare rättigheter att köra DELETE-kommandot.

2. Ta backup
Att ta backup på all data åtminstone en gång per dygn borde vara en självklarhet. Speciellt om man har flera miljoner användare.

3. Ge en rimlig kompensation
Om du klantar till det, visa att du tar det på allvar. Ge en kompensation som svider. När flickr erbjuder 4 års pro-medlemskap så förstår alla att det inte kostar dom ett öre. De kan med andra ord klanta till det hur många gånger som helst. De borde istället visa att det här var ett riktigt katastrofalt misstag, händer det igen förtjänar vi inte att få finnas kvar. Jag tycker inte en kompensation på $100 000 hade varit för mycket i det här fallet.

Till sist tycker jag att det är märkligt av flickr att överhuvudtaget stänga av konton för att de innehåller copyright-skyddat material. De borde kanske dölja de aktuella bilderna och varna medlemmen några gånger först innan de bestämmer sig för att radera alla dess bilder för all framtid.

UPPDATERING: Flickr lyckades tillslut återställa personens bilder, så någon backup hade de trots allt. 25 års pro-medlemskap fick han också vilket känns som en rimlig kompensation när de faktiskt fick tillbaka bilderna.