Many of these are debatable, obviously. But the only issue with mentioning is that I think it's a much better idea to send a developer that needs help with MyS

Many of these are debatable, obviously. But the only issue with mentioning is that I think it's a much better idea to send a developer that needs help with MySQL to, eg, the MySQL Performance Blog. Relational theory is hard stuff and I think a developer would be better served to understand a little bit about it than to just follow bullet points like those listed here. For example, indexing search fields. Could be a great suggestion. Could be a poor one. That depends on a lot of things. For example, not using natural keys. Same as above. For example, Enum over Varchar. Same story again. A lot of these are 100% harmless if your table has 1000 rows. But, honestly, if your table has 1000 rows you'll get good performance from MySQL no matter what you do. But take the Enum suggestion. Seems safe, right? But adding a value to an enum field forces a table rebuild. That's a blocking operation. And it could take quite a while on a big table. Also, it will change the way your data is sorted. Enums are sorted by their position in the enumeration, not alphabetically. So on, So Forth. The guys at percona and MySql performance blog are super informative. Spend some time there. You'll learn tons. And we've been using their storage engine in production on a write-intensive system for a year now and love it. Check it out.