7 (or so) deadly sins in MySQL

1. 7 (or so) Deadly Performance Sins
Martin Arrieta - Senior DBA @Percona

2. Same old Story
• We tend to get the same issues over and
over again
• Customers face similar challenges
• Some fixes are very easy and we need to
promote common knowledge
2

3. Let’s learn from others mistakes 3

4. Deadly Sin #1
More is not always better
4

5. • If 1 is good, 2 is better right?
• Lots of people resolve issues by throwing
more resources at it, this does not always
work
5

6. Overallocation of Memory
• People go hog wild on per session buffers like read_buffer,
read_rnd_buffer, join_buffer, and sort_buffer.
• What is the maximum amount of memory that MySQL can
use?:
• Per-session buffers * max connections
• + buffer pool size
• + key buffer size
• + some other buffers
6

7. Swapping is well known
• Most people know that swapping is bad, but
they still over-allocate memory
• Did you know disabling swap can be bad as well?
• TIP: Swappiness
• sudo sysctl -w vm.swappiness=1
• echo 1 > /proc/sys/vm/swappiness
7

8. More and More Indexes
• A lot of people is still indexing every column
• Waste Space
• Waste Memory
• Slow down inserts/updates/deletes
• Multi-key indexes are better than index
merges
8

9. Deadly Sin #2
Default Configurations
9

10. • Don't leave the my.cnf as default configs!
• MyISAM is the default storage engine on
<= 5.5.4
• I have seen companies spend tens of
thousands of dollars on big hardware but
not allocate memory to the database.
10

11. my.cnf
• Minimally set:
• InnoDB
• Buffer pool size
• Log size
• Transaction commit
• Key Buffer (still using MyISAM?)
• Query cache
11

12. my.cnf Parameters
• innodb_buffer_pool_size - Size of buffer pool
• innodb_log_file_size - Size of redo log
• innodb_flush_log_at_trx_commit - Flush
method
• key_buffer_size - Buffer for MyISAM index buffers
• query_cache_type and query_cache_size -
Query cache options
12

13. Deadly Sin #3
Using Too Much Space
13

14. How much data?
• What's this obsession with keeping data
forever?
• Purge your data! Is data from 1990
really needed?
• Summarize old data
• Do you need minute-by-minute or
hourly averages it is fine?
14

15. • There is a data Explosion going on
• Afraid to get rid of things
• Wasting space, just because we can
• Using tools that design the tables for
us.
15

16. Choosing the right data type
• Thin is always better!
• Smaller datatypes mean less storage per row on disk
• Less storage per row means faster retrieval of rows
• Less storage per row means more rows fit into
memory
• Size especially matters with InnoDB PK's! (more later)
• PK's are clustered indexes
• Every subsequent index contains the PK!
16

17. Large on Disk = Large on Memory
• For instance:
• 1M 8byte objects = 7.62MB of memory
• 1M 4byte objects = 3.81MB
• You could have saved 50% of your space
17

18. Integer data type 18

19. Deadly Sin #4
Not Understanding Indexing
19

20. Avoid the *solo* index on every column
• Too many indexes slow down inserts/updates
• Bloat disk and memory
• Index merges can happen in some cases, but
they are slower then multiple key indexes
• If the cardinality is bad, MySQL will ignore
them.
20

21. More on Indexes
• Remove redundant indexes
• KEY ( id ) and KEY ( id, type ) are
redundant!
• Order *does* matter
• (name, lastname) != (lastname, name)
• Run explain plan to see which indexes are
being used
21

22. GUID’s are *not* your friend
• GUID’s are 32 characters
• If your using utf8, thats 3bytes per character, or 96
bytes per guid
• In MySQL(InnoDB) the PK is duplicated in all
subsequent indexes
• 10 Million row table with 5 indexes would mean you
could potentially need 96bytes * 5 * 10 million rows
or about 4.5GB... using even a bigint (8 bytes )
instead would require about 400MB.
22

23. Deadly Sin #5
Bad backup strategy.
23

24. • Slave servers are NOT backups.
• Taking backups from slave? Are you
checking the data consistency?
• Do you test your backups regularly?
• Using only logical backups? Is your boss
happy with the time of the restore
process?
24

25. Questions?
25
martin.arrieta@percona.com
@MartinArrietaC