As your data grows, indexing may change (cardinality and selectivity change). Structuring may want to change. Make your schema as modular as your code. Make your code able to scale. Plan and embrace change, and get developers to do the same.

Network Performance Tips:

Minimize traffic by fetching only what you need.

Paging/chunked data retrieval to limit

Don’t use SELECT *

Be wary of lots of small quick queries if a longer query can be more efficient

Use multi_query if appropriate to reduce round-trips

OS Performance Tips:

Use proper data partitions

For Cluster. Start thinking about Cluster *before* you need them

Keep the database host as clean as possible. Do you really need a windowing system on that server?

Utilize the strengths of the OS

pare down cron scripts

create a test environment

source control schema and config files

for LVM innodb backups, restore to a different instance of MySQL so Innodb can roll forward

partition appropriately

partition your database when you have real data — do not assume you know your dataset until you have real data

MySQL Server Overall Tips:

innodb_flush_commit=0 can help slave lag

Optimize for data types, use consistent data types. Use PROCEDURE ANALYSE() to help determine the smallest data type for your needs.

use optimistic locking, not pessimistic locking. try to use shared lock, not exclusive lock. share mode vs. FOR UPDATE

InnoDB ALWAYS keeps the primary key as part of each index, so do not make the primary key very large

Utilize different storage engines on master/slave ie, if you need fulltext indexing on a table.

BLACKHOLE engine and replication is much faster than FEDERATED tables for things like logs.

Know your storage engines and what performs best for your needs, know that different ones exist.

ie, use MERGE tables ARCHIVE tables for logs

Archive old data — don’t be a pack-rat! 2 common engines for this are ARCHIVE tables and MERGE tables

use row-level instead of table-level locking for OLTP workloads

try out a few schemas and storage engines in your test environment before picking one.

Database Design Performance Tips:

Design sane query schemas. don’t be afraid of table joins, often they are faster than denormalization

Don’t use boolean flags

Use Indexes

Don’t Index Everything

Do not duplicate indexes

Do not use large columns in indexes if the ratio of SELECTs:INSERTs is low.

be careful of redundant columns in an index or across indexes

Use a clever key and ORDER BY instead of MAX

Normalize first, and denormalize where appropriate.

Databases are not spreadsheets, even though Access really really looks like one. Then again, Access isn’t a real database

use INET_ATON and INET_NTOA for IP addresses, not char or varchar

make it a habit to REVERSE() email addresses, so you can easily search domains (this will help avoid wildcards at the start of LIKE queries if you want to find everyone whose e-mail is in a certain domain)

A NULL data type can take more room to store than NOT NULL

Choose appropriate character sets & collations — UTF16 will store each character in 2 bytes, whether it needs it or not, latin1 is faster than UTF8.

Use Triggers wisely

use min_rows and max_rows to specify approximate data size so space can be pre-allocated and reference points can be calculated.

Use HASH indexing for indexing across columns with similar data prefixes

Use myisam_pack_keys for int data

be able to change your schema without ruining functionality of your code

segregate tables/databases that benefit from different configuration variables

Other:

Hire a MySQL ™ Certified DBA

Know that there are many consulting companies out there that can help, as well as MySQL’s Professional Services.