Thanks to all attendees of the webinar yesterday! If you missed it, you can watch the video recording.
Here are some questions that remained unanswered due to time constraints.
Q: Are there any technical considerations or best practice tips to have a replicated slave in the cloud, for example on Amazon AWS?
Hardware resources are usually limited in the cloud, and it is common that you prefer performance over data safety for a slave. So you may want to:
- relax InnoDB durability (innodb_flush_log_at_trx_commit)
- disable binary logging if it’s not useful
- look at the write queries that may cause replication lag and try to make them as efficient as possible
- have a look at indexes: the workload on slaves is often not the same as on the master, so they may benefit from different indexing
Q: Is there a Percona recommendation for finding Hot Spots in a high load application? Or some material to help determine these spots?
A good start is to enable full slow query logging (with long_query_time = 0) for some time during peak load. Then you can use pt-query-digest to analyze the queries and have a report of the queries that are causing the most load. You will sometimes see that a single query takes most of the total response time of the server: that’s typical of a hot spot and this query is a good candidate for optimization. I have even seen a case where one query was taking 90% of the total response time.
Q: Do you have a recommendation on when to use ENUM vs. CHAR? Especially for one character values?
Let’s say you want to store the status of an order for an e-commerce application. The status may be ‘payed’, ‘shipped’, ‘canceled’ or ‘archived’. If you use a string, a VARCHAR(15) could be good to store such values (A CHAR(8) too, but it will become a problem if you need to add an ‘unarchived’ status one day). Then each value will take 6 to 8 bytes for a single-byte character set (5 to 7 bytes for the value plus 1 byte to store the length of the value).
If you make the field an ENUM(‘payed’,'shipped’,'canceled’,'archived’), the values will be stored internally as an integer and they will only need 1 byte per value. If you have 100M records, it can make a huge difference! And when you write queries, you can still write conditions such as status = ‘payed’.
The downside of ENUMs is that if you need to add a new status, you will need to alter the table, which may be difficult if the table is big. So the best solution is sometimes to have an external tables to store the different status and only store the id of the status in the order table.
For one character values, the situation is a bit different as both CHAR(1) and ENUM will need 1 byte per value (again as long as you use a 1-byte character set for CHAR). Here CHARs will be more flexible and can avoid some subtleties of ENUMs due to their dual nature.
Q: Are these recommendations true of all versions of MySQL? If not which versions?
The recommendations I made are valid for all versions up to 5.5, and most should still be valid with 5.6.
Q: I have good command of SQL query writing and wanted to learn MySQL administration suggest any book or practices.
Of course I’m biased but High Performance MySQL 3rd edition is a very good book. The online documentation is also a valuable resource.
Q: Is any logical backup facility provided by Percona like mysqldump?
No, on the backup side, we’re focusing on XtraBackup, which performs raw backups.
The post Common MySQL traps webinar questions followup appeared first on MySQL Performance Blog.