month we talked about some things to set and tune in a new MySQL database
installation. We touched on connections, query cache, temp tables,
session memory, and the slow query log.
second part in the series hits on some other very important things to tune in a
new MySQL database.
is likely your storage engine of choice for MySQL as it provides transactional
support, as well as crash protection.
the InnoDB buffer cache should get the bulk of memory on the system. So
for example if you are just running MySQL on your server (we hope so), then perhaps
20% of the memory can go to the OS, 20-30% to sessions, and the remaining 50%
to static buffers in MySQL. If you're not using MyISAM most of that 50%
will be for this InnoDB buffer pool.
calculate innodb buffer pool hit ratio
1 - (innodb_buffer_pool_reads / innodb_buffer_pool_read_requests)
ratio is not a bulletproof way to tune I/O, but it can give you a good
indication and starting point from which to tune. Since InnoDB caches
both data and index in this buffer pool, the hit ratio here will tell you
overall the % of hits that are satisfied by going to memory versus the ones
which require disk I/O. You want to do as little disk I/O as possible, so
a higher hit rate here means you're caching better and more relevant blocks to
your applications needs.
MyISAM tables will be used less in your application. If you're using
FULLTEXT indexes, or BLOB datatype, you'll be using these types of
tables. Keep in mind that MySQL leaves caching of data blocks to the OS,
so only index blocks are stored in the key buffer.
buffer and then keep an eye on the hit ratios to tune dynamically. A good
starting point would be 64M or 128M. Also remember if you change the
variable dynamically, be sure to also update your my.cnf file to the same value
so the database will keep that value after restart.
calculate key buffer hit ratio
1 - ( key_buffer_reads / key_buffer_read_requests )
the innodb buffer cache hit ratio, this hit ratio tells you what percentage of
requests were satisfied from memory (a hit) versus going to disk (a
miss). Keeping this hit ratio high indicates that your cache is full of
blocks relevant to the SQL queries your application is running.
8. Tune Index Usage, Reduce Full Table Scans
always wish that databases had a setting index_usage, and you could just turn
that dial up to increase index usage. If only database tuning were so
simple! Reducing overall full table scans will go a long way towards
improving your MySQL server's performance and throughput.
we can calculate the percentage of table scans that are FULL TABLE SCANS.
1 - ( handler_read_rnd_next + handler_read_rnd ) /
( handler_read_rnd_next + handler_read_rnd + handler_read_first +
handler_read_next + handler_read_key + handler_read_prev )
should also enable the slow query log (mentioned in part one of this article),
and enable log_queries_not_using_indexes.
are a lot of different areas to be concerned about when considering
security. A few of the more important ones are as follows:
the query below to view the users on your system. Be sure they all have a
password, especially the root account. Also, be sure there is a host
specified, not a wildcard, as this allows that user to connect from any host on
the internet! Most likely, the host's column should contain localhost,
known webservers that connect to this database, and perhaps one or two remote
mysql> use mysql;
mysql> select user, host, password from user;
| user | host | password |
| admin | localhost | 441f54c126b8f67f |
| pma_IiabUsiU1n6q | localhost | 6c4572a01bdfb70d |
| horde | localhost | 31e43e9079b4ad01 |
| root | localhost | 164bbc8331b849bd |
| drupal | localhost | 4bddbbde31e8ecb3 |
| phplist | localhost | 4bddbbde31e8ecb3 |
| backup | localhost | 164bbc8331b849bd |
check secure_auth and be sure it is set to ON. If you don't specifically
need it, disable have_symlink, which allows files to be moved around and symlinked,
but can also be used for nefarious purposes as well. We also suggest you
set skip_show_database to ON as well, which prevents users from seeing other
"databases" or schemas inside your MySQL server. Also unless
you specifically need it, set local_infile as well to OFF.
are many useful and relevant logfiles in MySQL, so you should look specifically
at those and make sure they are enabled. They can help immeasurably in
problem resolution. We talked about the slow query log previously; here
are the rest.
enable the binary log with the log_bin parameter. By itself, it turns on
binary logging. You can also specify a filename. Enabling the
binary log is required for doing point in time recovery. You can also use
the mysqlbinlog tool to view exactly what queries are in the binary log,
timestamps and everything. This is powerful for problem resolution as
well. Also, if you are using replication, you'll need to enable the
binary log. Also set expire_logs_days to the number of days worth of old
binary logs you want to keep around. If you do backups every seven days,
then you'll need at *least* seven days worth of binary logs to do point in time
slow query log, this facility logs queries, but in this case *all* queries that
funnel through your database. This can be a useful feature to have, but
can also grow large very quickly, so be sure to trim and/or rotate the logfile
has a lot of system variables, the proverbial dials on a complex piece of machinery.
However if you focus on a few important areas, you'll get your database in good
See All Articles by Columnist Sean Hull