mysql tips

links: http://forge.mysql.com/wiki/Top10SQLPerformanceTips

Query Performance Tips (see also database design tips for tips on indexes):   
Use EXPLAIN to profile the query execution plan
    Use Slow Query Log (always have it on!)
    Don't use DISTINCT when you have or could use GROUP BY
    Insert performance
        Batch INSERT and REPLACE
        Use LOAD DATA instead of INSERT
    LIMIT m,n may not be as fast as it sounds. Learn how to improve it and read more about Efficient Pagination Using MySQL
    Don't use ORDER BY RAND() if you have > ~2K records
    Use SQL_NO_CACHE when you are SELECTing frequently updated data or large sets of data
    Avoid wildcards at the start of LIKE queries
    Avoid correlated subqueries and in select and where clause (try to avoid in)
    No calculated comparisons -- isolate indexed columns
    ORDER BY and LIMIT work best with equalities and covered indexes
    Separate text/blobs from metadata, don't put text/blobs in results if you don't need them
    Derived tables (subqueries in the FROM clause) can be useful for retrieving BLOBs without sorting them. (Self-join can speed up a query if 1st part finds the IDs and uses then to fetch the rest)
    ALTER TABLE...ORDER BY can take data sorted chronologically and re-order it by a different field -- this can make queries on that field run faster (maybe this goes in indexing?)
    Know when to split a complex query and join smaller ones
    Delete small amounts at a time if you can
    Make similar queries consistent so cache is used
    Have good SQL query standards
    Don't use deprecated features
    Turning OR on multiple index fields (<5.0) into UNION may speed things up (with LIMIT), after 5.0 the index_merge should pick stuff up.
    Don't use COUNT * on Innodb tables for every search, do it a few times and/or summary tables, or if you need it for the total # of rows, use SQL_CALC_FOUND_ROWS and SELECT FOUND_ROWS()
    Use INSERT ... ON DUPLICATE KEY update (INSERT IGNORE) to avoid having to SELECT
    use groupwise maximum instead of subqueries
    Avoid using IN(...) when selecting on indexed fields, It will kill the performance of SELECT query.
    Prefer using UNION ALL if you don't need to merge the result

Scaling Performance Tips:

    Use benchmarking
    isolate workloads don't let administrative work interfere with customer performance. (ie backups)
    Debugging sucks, testing rocks!
    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
    Use stored procedures to avoid bandwidth wastage

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
    Reduce swappiness of your OS

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
    if you can, compress text/blobs
    compress static data
    don't back up static data as often
    enable and increase the query and buffer caches if appropriate
    config params -- http://docs.cellblue.nl/2007/03/17/easy-mysql-performance-tweaks/ is a good reference
    Config variables & tips:
        use one of the supplied config files
        key_buffer, unix cache (leave some RAM free), per-connection variables, innodb memory variables
        be aware of global vs. per-connection variables
        check SHOW STATUS and SHOW VARIABLES (GLOBAL|SESSION in 5.0 and up)
        be aware of swapping esp. with Linux, "swappiness" (bypass OS filecache for innodb data files, innodb_flush_method=O_DIRECT if possible (this is also OS specific))
        defragment tables, rebuild indexes, do table maintenance
        If you use innodb_flush_txn_commit=1, use a battery-backed hardware cache write controller
        more RAM is good so faster disk speed
        use 64-bit architectures
    --skip-name-resolve
    increase myisam_sort_buffer_size to optimize large inserts (this is a per-connection variable)
    look up memory tuning parameter for on-insert caching
    increase temp table size in a data warehousing environment (default is 32Mb) so it doesn't write to disk (also constrained by max_heap_table_size, default 16Mb)
    Run in SQL_MODE=STRICT to help identify warnings
    /tmp dir on battery-backed write cache
    consider battery-backed RAM for innodb logfiles
    use --safe-updates for client
    Redundant data is redundant
    Keep an eye on buffer pool and keybuffer hit rate

Storage Engine Performance Tips:

    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.
    Split out large blob elements in InnoDB
    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
    Avoid NULL in index attributes. Use 0 instead
    Storing flags in a database can slow down execution due to a bad cardinality. Try using bit flags
    Don't store flags in a NULL and NOT NULL manner. Update from NULL -> 1 is slower than 0 -> 1
    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 delayed key wrote
    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
    Don't access the last key part in a where clause with =
    Abuse the system for optimiization you're using with system dependant features like RTREE's for optimized range queries

Other:

    Hire a MySQL (tm) Certified DBA
    Know that there are many consulting companies out there that can help, as well as MySQL's Professional Services.
    Read and post to MySQL Planet at http://www.planetmysql.org
    Attend the yearly MySQL Conference and Expo or other conferences with MySQL tracks (link to the conference here)
    Support your local User Group (link to forge page w/user groups here)