MySQL DBA Training Session 19.

Optimizing MySQL Schemas

RAM N SANGWAN
WWW.RNSANGWAN.COM
YOUTUBE CHANNEL HT TP://YOUTUBE.COM/USER/THESKILLPEDIA
WANT TO LEARN OR TEACH JOIN WWW.THESKILLPEDIA.COM

WWW.RNSANGWAN.COM 1
Who am I?
• Corporate Trainer
• More than 25 Years of Experience.
• More than 50 Technologies
• Managing Alliance Softech Pvt Ltd as Managing Director
• Running More than 300 Live Websites
• Major Technologies
◦ RDBMS : MySQL, Sybase (Now SAP ASE), DB2, Oracle, SQL Server, SAP HANA
◦ Linux : Virtualization, High Availability, Deployment
◦ PHP, Perl, Python
◦ Storage Technologies
◦ Many More…

WWW.RNSANGWAN.COM 2
Agenda
• Normalization
• Table Optimizations
• Index Optimizations
• MyISAM-Specific Optimizations
• MyISAM Specific configuration
• InnoDB Specific configuration
• InnoDB-Specific Optimizations
• MEMORY-Specific Optimizations

WWW.RNSANGWAN.COM 3
Normalization
• Normalization is a key factor in optimizing your database structure
• Good normalization prevents redundant data from being stored in the same
tables
• By moving redundant data to their own table, this reduces storage
requirements and overhead when processing queries
• Transactional databases should be in the 3rd normal form

WWW.RNSANGWAN.COM 4
Table Optimizations
• Use columns that are as short as possible;
INT instead of BIGINT
VARCHAR(10) instead of VARCHAR(255)
– etc.
• Pay special attention to columns that are used in joins
• Define columns as NOT NULL if possible

WWW.RNSANGWAN.COM 5
Index Optimizations
• An index on the whole column is not always necessary
• Instead index just a prefix of a column
• Prefix indexes take less space and the operations are faster
◦ Composite indexes can be used for searches on the first column(s) in the index
◦ Minimize the size of PRIMARY KEYs that are used as references in other tables
• Using an auto_increment column can be more optimal
• A FULLTEXT index is useful for
◦ word searches in text
◦ searches on several columns

WWW.RNSANGWAN.COM 6
 MyISAM-Specific Optimizations
• Consider which row format to use, dynamic, static or compressed
◦ Speed vs. space
• Consider splitting large tables into static and dynamic parts
• Perform table maintenance operations regularly or after big DELETE/UPDATE operations
◦ Especially on tables with dynamic row format

WWW.RNSANGWAN.COM 7
MyISAM Specific configuration
concurrent_insert
• Allows for inserts into MyISAM tables without blocking reads
• If a MyISAM table has no holes in the data file, an INSERT statement can be
executed to add rows to the end of the table at the same time that SELECT
statements are reading rows from the table.
• By default, the variable is set to AUTO (or 1)
• If concurrent_insert is set to NEVER (or 0), concurrent inserts are disabled.
• If the variable is set to ALWAYS (or 2), concurrent inserts at the end of the
table are permitted even for tables that have deleted rows.

WWW.RNSANGWAN.COM 8
MyISAM Specific configuration Contd..
delayed_key_write
• Delays flushing to disk for index changes to batch the changes for greater
performance.
• The risk is that a data corruption could be caused by a system crash, but as it
is only indexes these can be rebuilt on starting up the database.

WWW.RNSANGWAN.COM 9
MyISAM Specific configuration Contd..
key_buffer
• This configures the size of the MyISAM index buffer, remember MyISAM does not buffer the
data so only the caching of data is done by the operating system buffers.
• The cache ratio is the number of times a value in the buffer was read as a total percentage of
the total number of times a value in the buffer was looked for, to determine the cache hit ratio
run show global status like '%key_read%' and use the key_read and key_read_requests
status variables in the formula below
hit_ratio = (key_reads / key_read_requests) * 100
• To increase the buffer use the key_buffer option to set the key_buffer_size larger
• The formula to find the percentage of the index buffer that is in use, look for about 80% usage
100 * (1 - (key_blocks_unused * key_cache_block_size) / key_buffer_size)

WWW.RNSANGWAN.COM 10
InnoDB Specific configuration
• Do not use defaults
• Default settings are for toy databases
◦ 8MB buffer pool, 10MB logs size
◦ Not enough for any serious load
• Innodb is affected by buffer sizes much more than MyISAM
◦ Advanced caching
◦ Synchronous IO

WWW.RNSANGWAN.COM 11
InnoDB Specific configuration Contd..
innodb_buffer_pool_size
• A static variable that specifies the size of the cache for InnoDB data and indexes, give
generously if using a lot of InnoDB tables. Ideally 50-70% of your systems memory.
◦ If Innodb is only your storage engine
• To calculate the ratio of unused data pages to the total number of pages the formula below
can be used
Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total
• If the ratio is high (close to 1) the Innodb buffer pool is probably set to high, a less likely cause
is that the innodb_max_dirty_pages_pct system variable is set to low and dirty pages are
being flushed very often, freeing up pages long before they are needed.

WWW.RNSANGWAN.COM 12
InnoDB Specific configuration Contd..
innodb_flush_log_at_trx_commit
• There are three options (0|1|2), this dynamic variable manages how often the
InnoDB log buffer is written (flushed) to the log file
innodb_flush_log_at_trx_commit = 1 // best durability
innodb_flush_log_at_trx_commit = 2 // better performance
innodb_flush_log_at_trx_commit = 0 // best performance

WWW.RNSANGWAN.COM 13
InnoDB Specific configuration Contd..
innodb_flush_method
• This static variable determines how InnoDB storage engine interacts with the operating
system in respect to I/O operations, there are three methods
◦ fsync is the default option and uses fsync() system call to flush the data and log files
◦ O_DIRECT will bypass the operating system cache for both reads and writes of data and log
files
◦ O_SYNC uses the fsync() system call for data files but for log files it uses O_SYNC
O_DIRECT will provide you with better performance but make sure the RIAD controller has a battery backed up
write cache, again make sure you test before making it your standard.

WWW.RNSANGWAN.COM 14
InnoDB Specific configuration Contd..
innodb_log_buffer_size
• Buffer used for writes to InnoDB logs, unless you use very large BLOBs this
static variable should not be over 8MB
innodb_log_files_in_group
• A static variable that determines the size of each InnoDB log file

WWW.RNSANGWAN.COM 15
InnoDB Specific configuration Contd..
innodb_max_dirty_pages_pct
• This dynamic variable specifies the maximum percentage of pages in the
InnoDB buffer pool that can be dirty, this defaults to 90%
innodb_thread_concurrency
• This dynamic variable determines the maximum number of system threads
inside InnoDB, a good start would be twice the number of CPU's.

WWW.RNSANGWAN.COM 16
InnoDB Specific configuration Contd..
key_buffer_size
• May be still needed for temporary tables
• Some 32MB is enough
log_buffer_size
• 4-8MB is enough for most cases

WWW.RNSANGWAN.COM 17
InnoDB Specific configuration Contd..
innodb_file_per_table
• Use its own tablespace for each table
• System tablespace is still used for undo segments and metadata
• Easier to backup, reclaim space
• Performance effect varies
• Problems with very large number of tables
• Less tested than default configuration

WWW.RNSANGWAN.COM 18
InnoDB-Specific Optimizations
• InnoDB uses clustered indexes
◦ The length of the PRIMARY KEY is extremely important
• The rows are always dynamic
◦ Using VARCHAR instead of CHAR is almost always better
• Maintenance operations needed after many UPDATE/DELETE operations
• The pages can become under-filled

WWW.RNSANGWAN.COM 19
MEMORY-Specific Optimizations
• Use BTREE (Red-black binary trees) indexes
◦ When key duplication is high
◦ When you need range searches
• Set a size limit for your memory tables
◦ With --max_heap_table_size
• Remove unused memory
◦ TRUNCATE TABLE to completely remove the contents of the table
◦ A null ALTER TABLE to free up deleted rows

WWW.RNSANGWAN.COM 20
Thank You

WWW.RNSANGWAN.COM 21