--- Storage Engine Statistics [--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 6G Tables: 128 ---[--] Data in InnoDB tables: 21G Tables: 44 [--
Trang 1For some status variables, such asSlave_running, the current output is enoughinformation — either the slave is running or it is not TheThreads_connectedstatusvariable shows how many threads are currently connected However, for many status variables,there is more to be done than simply looking at the value of each variable For example, theSlow_queriesstatus variable provides a count of how many slow queries the system haslogged:
mysql> SHOW GLOBAL STATUS LIKE ’Slow_queries’;
+ -+ -+
| Variable_name | Value | + -+ -+
| Slow_queries | 1073 | + -+ -+
1 row in set (0.00 sec)
Is it good or bad that there have been 1073 slow queries? You should investigate and optimizeall the slow queries that are logged — see themysqldumpslowandmysqlslatools discussedlater in this chapter for how to find slow queries, and see Chapter 18 for how to analyzequeries
When determining the health of a system, the important data is how frequently slow queries arehappening TheUptimestatus variable shows how long, in seconds, that particularmysqldhasbeen running:
mysql> SHOW GLOBAL STATUS WHERE Variable_name=’Slow_queries’
-> OR Variable_name=’uptime’;
+ -+ -+
| Variable_name | Value | + -+ -+
| Slow_queries | 1073 |
| Uptime | 10906 | + -+ -+
2 rows in set (0.08 sec)The server has been up for 10906 seconds (or roughly seven and a half days);
The rate of slow queries is an average of about one slow query every 10 seconds Ideally, youwould like to be able to see the rate of change over time For example, the slow query infor-mation you saw earlier would indicate a problem in a database that usually has one slow queryevery hour; the database administrator would be celebrated in a database that usually has oneslow query every second Establishing a baseline for a system’s status and comparing over timewill make patterns evident and shows where problems may lurk
One way to establish a baseline is to compare the status variables over a short period of time
To get an average of status variables in an hour, you can compare the output ofSHOW GLOBAL STATUStaken from a server at 1 pm to the output of SHOW GLOBAL STATUStaken from thesame server at 2 pm Instead of comparing variables toUptime, variables are compared to each
Trang 2other We may find that from 1–2PM, there are only two slow queries, but from 2-3PM, thereare ten slow queries.
With about 300 status variables, manual analysis is tedious However, no automated tool cantake into consideration the specifics of your system, and what is acceptable to your users There
is a tradeoff to using automated tools, which may be acceptable Even if you use an automatedtool or tools, knowing how to useSHOW GLOBAL STATUSis a key skill for a database administra-tor working withmysqld
mysqltuner
The open source programmysqltuneris a Perl script that is a part of the default packagedistribution for some operating systems If it is not part of your operating system, youcan download it atwww.mysqltuner.com It can be run with no options — by default,mysqltuner.plconnects tomysqldon localhost port 3306, and prompts for a username andpassword:
shell> /mysqltuner.pl
>> MySQLTuner 0.9.9 - Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at http://
■ Check neutral or skipped [ ]
■ Check OK [OK]
■ Warning, check not OK [!!]
Before the first section,mysqltunerwill output a problem if the password provided is blank:[!!] Successfully authenticated with no password - SECURITY RISK!
Trang 3General Statistics
There are three checks in theGeneral Statisticssection The first is whether or not there is
a new version ofmysqltuner This is skipped by default, but can be turned on by giving the checkversionflag tomysqltuner The second check determines which version ofmysqldyou are running, and whether or not that version is supported bymysqld If you are running a
version that has been marked as end of life by Sun Microsystems, a warning will be issued The
final check is whether or not the operating system is 64 bit
- General Statistics [ ] Skipped version check for MySQLTuner script
-[!!] Currently running unsupported MySQL version community-log
6.0.6-alpha-[OK] Operating on 64-bit architecture
If the system is running a 32-bit architecture with 2 GB of RAM or less,mysqltunernotes:
[OK] Operating on 32-bit architecture with less than 2GB RAMOtherwise, you get a warning:
[!!] Switch to 64-bit OS - MySQL cannot currenty use all of your RAM
Storage engine statistics
This section analyzes the sizes and storage engines of tables, except for tables in themysqlandinformation_schemadatabases At the time of this writing,mysqltunerdoes not give anydetails about the Falcon or Maria storage engines.mysqltunerusesSHOW TABLE STATUSinpre-5.0 database servers to determine the size of each table and whether or not the table is frag-mented With MySQL 5.0 and above, it uses theinformation_schemadatabase to gather thesame information It prints out a list of the total data stored in each table type and ends with acount of fragmented tables
- Storage Engine Statistics [ ] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [ ] Data in MyISAM tables: 6G (Tables: 128)
-[ ] Data in InnoDB tables: 21G (Tables: 44) [ ] Data in MEMORY tables: 0B (Tables: 1) [!!] Total fragmented tables: 7
It is important to note that the size ofData_lengthinSHOW TABLE STATUSor the tion_schemadatabase is not always accurate For storage engines that estimate the size of theirdata the size shown will be an approximation Also, the size of indexes is not taken into consid-eration, so this information cannot be used to figure out how much space the database is using.TheData_freefield of eitherSHOW TABLE STATUSor theinformation schema TheTABLESdatabase is used to determine whether a table is fragmented or not IfData_freeis greater
Trang 4informa-than zero,mysqltunerconsiders the table fragmented This may lead to false warnings whenusing global InnoDB data files (i.e., not usinginnodb_file_per_table), asData_freeshows the amount of data left in the global InnoDB data files.
If a storage engine is enabled, but there are no tables that are defined with that storage engine,mysqltunerwill issue a warning such as:
[!!] InnoDB is enabled but isn’t being used
A false positive may arise if you runmysqltunerwith a user that cannot see all the tableswithinmysqld, as the storage engine may actually be in use by a table that the user does nothave permissions to see
Performance Metrics
ThePerformance Metricssection uses the output fromSHOW GLOBAL STATUSand performsthe tedious calculations you would ordinarily do by hand The first line gives a general overview
of mysqld: - Performance Metrics -
Up for:116d 21h 10m 14s (338M q[33.501 qps],39M conn,TX:174B,RX: 28B)The values in the first line are simply the status variables fromSHOW GLOBAL STATUSwith someformatting for better readability, as shown in Table 17-10:
TABLE 17-10
Relationships between Variables in Performance Metrics and SHOW
GLOBAL STATUSPerformance Metrics Variable Status Variable from SHOW GLOBAL STATUS
The next line gives the percentage of reads and writes, using theCom_selectstatus variable
as the number of reads, and the sum of theCom_delete,Com_insert,Com_update,Com_replacestatus variables as the writes The percentage given is a percentage of the totalreads and writes (all fiveComvariables added together) and does not include administrativecommands likeSHOW Because of this, these percentages may be misleading
[ ] Reads / Writes: 32% / 68%
Trang 5The next two lines relate to memory usage:
[ ] Total buffers: 1.9G global + 12.2M per thread (300 max threads) [!!] Maximum possible memory usage: 5.5G (91% of installed RAM)Information for these lines comes from the system variables that are the output of SHOW GLOBAL VARIABLES
Theglobalbuffer formula thatmysqltuneruses is:
key_buffer_size + max_tmp_table_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size + innodb_log_buffer_size + query_cache_size
Theper threadbuffer formula thatmysqltuneruses is:
read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size
Themax_threadscomes from the system variablemax_connections.TheMaximum possible memory usageis calculated by:
global + max_connections * (per thread)Theglobalandper threadbuffers inmysqltunerare not a complete picture of how muchmemory is allocated for global use; they do not take into account any of the memory settings forthe BDB, Falcon, and Maria storage engines Thus, theMaximum possible memory usageisinaccurate
TheMaximum possible memory usagein our example is a large percentage of available ory In some cases, it may exceed the memory available This may or may not be a problem; inmany cases, there will not bemax_connectionsnumber of connections that are all using themaximumper threadmemory allocation In fact, there may be a few queries that require highvalues for some of theper threadmemory variables Themax_connectionsvariable is use-ful to reduce the number of connections, so thatmysqlddoes not crash by trying to allocatemore memory than is available However, there are many cases in which both a high number ofmax_connectionsand a high number of per threadmemory variables are needed This isone of the reasons that automated tuning is not always useful
mem-The values in the rest of thePerformance Metricssection are simple calculations involvingsystem and status variables fromSHOW GLOBAL VARIABLESandSHOW GLOBAL STATUS:[OK] Slow queries: 0% (4K/338M)
[OK] Highest usage of available connections: 34% (102/300) [OK] Key buffer size / total MyISAM indexes: 350.0M/13.7G [OK] Key buffer hit rate: 97.2% (368M cached / 10M reads) [!!] Query cache efficiency: 14.1% (12M cached / 90M selects) [!!] Query cache prunes per day: 246
[OK] Sorts requiring temporary tables: 8% (1M temp sorts / 19M sorts) [OK] Temporary tables created on disk: 12% (162K on disk / 1M total) [OK] Thread cache hit rate: 99% (102 created / 39M connections) [OK] Table cache hit rate: 53% (358 open / 675 opened)
Trang 6[OK] Open file limit used: 1% (310/25K) [OK] Table locks acquired immediately: 100% (236M immediate / 236M locks)
[!!] InnoDB data size / buffer pool: 21.3G/1.5G Recommendations
- Recommendations General recommendations:
-Run OPTIMIZE TABLE to defragment tables for better performance Variables to adjust:
*** MySQL’s maximum memory usage exceeds your installed memory ***
*** Add more RAM before increasing any MySQL buffer variables *** query_cache_limit (> 2M, or use smaller result sets)
query_cache_size (> 64M) innodb_buffer_pool_size (>= 21G)
Performance and Reporting Options skipsize Don’t enumerate tables and their types/sizes checkversion Check for updates to MySQLTuner
forcemem <size> Amount of RAM installed in megabytes forceswap <size> Amount of swap memory configured in MB Output Options:
nogood Remove OK responses nobad Remove negative/suggestion responses noinfo Remove informational responses nocolor Don’t print output in color
As you can see, the information provided by mysqltunercan be quite valuable However, anyrecommendations from this (or other) profiling programs should be taken with some caution
It is very easy to make changes just based on the recommendations of mysqltuner, withoutunderstanding what is really happening, and have a system that does not perform as optimally
as possible
mysqlreport
Themysqlreportprogram is similar in scope tomysqltuner Likemysqltunerit is
a Perl program that uses theSHOW STATUScommand to gather an overall picture of aserver’s health Unlikemysqltuner, themysqlreportprogram does not provide anyrecommendations However, it does provide a more in-depth analysis of your system thatyou can use to determine where changes need to be made The program is available athttp://hackmysql.com/mysqlreport
Running the program is not difficult:
Trang 7After you are prompted for the password, the report is generated While this is the simplest way
to runmysqlreport, there are a number of options used for connecting tomysqldand ing themysqlreportprogram run Table 17-11 lists the available options
infile file_name Reads status information from file_name instead of
connecting to a server and running SHOW STATUS and SHOW VARIABLES commands.
outfile file_name Writes report to both the file named file_name and the
screen.
email email_address On Unix-based systems emails report to email_address.
flush-status After gathering the current values issues a FLUSH STATUS
command.
relative value By default, mysqlreport generates a report based on the
status of the server since it began operation The relative option can be used to generate reports that are based on the values from previous reports If value is
an integer the reports are generated live from mysqld every num seconds The option value can also be a list of input files (generated by running mysqlreport with the report-count option), and the relative report is generated from these input files in the order specified.
report-count num Collects num number of reports for use as input files for the
relative option.
detach Runs the mysqlreport program in the background.
help Prints help information and exits.
debug Prints debugging information and exits.
Trang 8As withmysqltuner, themysqlreportprogram generates a report with sections devoted tovarious aspects of mysqldbeing analyzed The header section provides some general informa-tion about what version of MySQL is running, how long the server has been running and thetime the report was generated.
shell> /mysqlreport user qa_user password Password for database user qa_user:
MySQL 5.0.45-Debian_1ub uptime 27 22:47:2 Tue Sep 23 23:56:20 2008
The next section is the Key section and covers information about the key buffer usage The keybuffer is the buffer used to store MyISAM indexes
Key _ Buffer used 13.08M of 16.00M %Used: 81.76
Current 16.00M %Usage: 100.00 Write hit 96.88%
Read hit 99.22%
The first line of the Key section should be ignored Buffer used is suppose to show the highestever level of buffer usage However, it is very often inaccurate In this example, it shows a max-imum of 13.08 megabytes used The Current line shows the buffer amount currently being uti-lized In this case, the entire 16 MB is being utilized
TheWrite hitvalue can vary quite a lot, depending on your overall server usage Ifmysqldhas a lot of write activity that primarily executesINSERTandUPDATEstatements, thenWrite hitmay be very low If your server has a high percentage ofSELECTstatement execution, thenthe keyWrite hitmay be close to 100 percent However, a negative keyWrite hitindicatesthat MySQL is writing keys to hard disk more frequently than the key buffer in RAM This isgoing to be slow
TheRead hitvalue shows the ratio of key reads from hard disk to key reads from memory.This percentage should be very high — near 100 percent Having your MyISAM table indexesstored in the key buffer is going to provide for much faster updating than having the indexesstored on disk If this value is not very close to 100 percent, you should see a performanceincrease by allocating more memory to the key buffer
The next section, Questions, includes information about both SQL queries being executed andthe MySQL protocol communications:
Trang 9TheTotalline shows how many total questions were processed by the server It is simply asummation of the two fields of data While it is somewhat disingenuous, you can say that thesecond field of theTotalline is your server’s query per second average In the case of theserver being profiled, it doesn’t execute very many queries per second.
After theTotalline, all of the lines following are sorted based upon frequency In the case ofthe server being profiled, the DMS statements were the majority of the total questions executed
by the server The DMS line shows statistics about Data Manipulation Statements (SELECT,INSERT,UPDATE, andDELETEqueries) The majority of the server processing should be DMLstatements, and if it is not, it probably indicates a problem TheCom_ linedisplays the servercommunication commands, and theQC Hitsline shows how many query result sets wereserved from the query cache In the case of the profile server, it is not a significant percentage(2.21%) There is a significant amount of data about the query cache later in the report, so itwill be examined more closely at that point TheUnknownline should be fairly small Unknownquestions are the questions that MySQL handles and increments the total questions counter butdoes not have a separate status value to increment TheSlowline shows how many queriestook longer than the server variablelong_query_timeto return a result With the server beingprofiled thelong_query_timeis10 s(seconds)
In addition to these lines showing general information, the Questions section provides a rate subsection for each line With the server being profiled for the example, the most activityoccurred with data manipulation statements, so it is the first subsection
This subsection can tell you at a glance how read or write heavy the application is In this case,
it is almost entirely writes (99.34%) This is very unusual This also explains why the earlier
per-centage for queries served out of the query cache is so low
For the profiled server, the next subsection is theCom_subsection:
show_status 517.09k 0.2/s 3.64 set_option 352.17k 0.1/s 2.48TheCom_subsection shows the values for the most usedCom_commands on the profiledserver If you have some very unusual activity, it might show up here
SELECT and Sort
Scan 758.38k 0.3/s %SELECT: 1407.6
Trang 10a multi-table queries Both of these values should be as low as possible.
The other values tend not to impact performance If you want more information about them,complete documentation is available online athttp://hackmysql.com
Notice that theScanline has a percentage value of 1407.6 Since the total for all these valuesshould add up to 100 percent, this is clearly incorrect Be careful when going through thisreport, as there are occasional glitches
Query Cache Memory usage 361.34k of 32.00M %Used: 1.10
Block Fragmnt 11.36%
Inserts 42.09k 0.0/s Insrt:Prune 42.09k:1 0.0/s Hit:Insert 7.45:1
As stated earlier, this server is very heavy on writes Because of this the query cache is not usedvery much TheMemory usageline shows the amount of memory actually being used out ofthe total memory allocated to theQuery Cache In this case, it is 361.34k out of 32 MB TheBlock Fragmentpercentage should be somewhere between 10 and 20 percent It indicates theamount of fragmentation in the query cache TheHits lineindicates the number of queryresult data sets actually served from the query cache This should be as high as possible Foradditional details one query cache optimization, see Chapter 12
The next two lines are ratios that indicate the general effectiveness of your query cache The firstline,Insert:Prune, is the ratio of inserts (into the query cache) toprunes A prune is when
a query is removed from the query cache In this case, the ratio is very heavy on inserts becauseprunes are not really happening If the amount of prunes is very large, it might be beneficial toincrease the size of the query cache TheHit:Insertratio shows the number of hits (results)returned from the query cache versus the number of inserts into the query cache The higherthis ratio is the better your server performance For additional details on query cache optimiza-tion, see Chapter 12
Table Locks
Immediate 8.33M 3.4/s
Trang 11The Table Locks subsection shows how often the database had to wait to obtain a lock on atable (Waited) and how often the lock was granted immediately (Immediate) If the databasehad to wait for table locks very often, this indicates there often a problem with MyISAMcontention.
If the number of open tables is equal to the table cache, it could possibly indicate a problem
You might want to increase the size of the table cache
num- Created Temp num- num- num- num- num- num- num- num- num- num- num- num- num- num- num- num- num- num- num- num- num- num- num- num- _
Disk table 159.56k 0.1/s Table 745.02k 0.3/s Size: 128.0M
Trang 12The Threads subsection details information about the threads used for each connection to theserver The most important line in this subsection isCached It shows the number of threadsthat are stored in the thread cache ready for reuse This keeps the server from having to create
a new thread for a new connection The cache hit rate of 99.99 percent is excellent If it isnot very high, it indicates that the server has to continually create and destroy new threads,which can impact performance If this is the case, you should probably increase the size of thethread cache
Aborted _
The Aborted subsection show statistics about connections to the server that have been dropped
If this number is very high in relation to the amount of uptime, it can indicated a problem TheClientsline shows connections that are closed because of three possibilities:
■ The client program did not callmysql_close()before exiting
■ The client has been sleeping more seconds than the values of either of the two system ableswait_timeoutorinteractive_time
vari-■ The client program ended in the middle of a data transfer
TheConnectsline is incremented when one of four things happens:
■ The client does not the required privileges to connect to the database
■ The client used an incorrect password
■ A connection packed is malformed or doesn’t contain the proper information
■ It takes the server more thanconnect_timeoutseconds to get a connection packet formthe client
Bytes
Sent 121.68G 50.4k/s Received 8.78G 3.6k/sThe Bytes subsection shows the number of bytes sent from and received by the server:
InnoDB Buffer Pool _
Usage 511.98M of 512.00M %Used: 100.00 Read hit 99.94%
Trang 13Ahead Rnd 12536 0.0/s Ahead Sql 3729 0.0/s Writes 104.87M 43.4/s
The Reads subsection shows the read activity of the buffer pool TheReadsline shows the totalread activity both in number of reads and the average amount of reads per second TheFrom fileline shows the number of reads of InnoDB pages that were served from hard disk instead
of memory A high number here is an indication of poor performance Reads from memory arealways going to be faster than reads from storage The twoAheadlines detail the number ofread ahead requests that are random (Rnd) or Sequential (Sql) These sequential read-aheadreads indicate full table scans, which are a performance issue
TheWritelines describe the total number and average rate of writes to the buffer pool Thissystem is quite busy with write activity, and it is shown here TheFlushesline indicates thetotal and per second average number of flushes (writing data changes from the buffer pool todisk) TheWait Freeline indicates the number of times and the average that when the bufferpool attempts to create a new page and there are no clean pages available When this happens,
it is necessary to wait for the dirty pages to be flushed This number should be low when pared to the total read numbers
The InnoDB Lock subsection details information about the row-level locks for InnoDB tables
Ideally, these statistics will be at or near zero TheWaitsline shows the total and average
Trang 14number of times the server had to wait for the release of a lock on an InnoDB row TheCurrentline shows the number of locks the server is waiting for at the time the report isrun The Time acquiring section shows the total, average, and maximum amount of time (inmilliseconds) the server waited for rows locks.
InnoDB Data, Pages, Rows _
Data Reads 482.10k 0.2/s Writes 16.53M 6.8/s
Written 8.93M 3.7/s Rows
Deleted 609.09k 0.3/s Inserted 5.86M 2.4/s Read 529.57M 219.3/s Updated 10.08M 4.2/sThe InnoDB Data, Pages, Rows subsection provides very general information about InnoDBactivity It can be used as a quick overview before moving to the appropriate subsection formore detailed information
Overall themysqlreportprogram provides very good information about the activity of yourserver You can use it to provide a profile of your operational servers and see potential troublespots or places for improvement
mk-query-profiler
Themk-query-profilerscript reads a file containing SQL statements or shell commands,executes them, and performs analysis of the output ofSHOW STATUS At the end of programexecution, it displays statistics about query performance
If the batch file contains multiple queries, it is necessary to separate the queries by blanklines If the queries are not separated, then query execution onmysqldwill fail becausemk-query-profilercan not split the individual queries apart Table 17-12 lists the optionsavailable formk-query-profiler
Trang 15askpass Will ask for a password when connecting to mysqld.
[no]calibrate or -c The script attempts to compensate for the SHOW STATUS
query execution Defaults to yes.
charset or -A Determines the default character set.
database or -D Determines the database used for query execution.
defaults-file or -F The script read mysql options from the specified files,
which must have an absolute pathname.
external or -e The script calibrates and then pauses while you run an
external program When your external program is finished, you must press the Enter key again to resume execution.
port or -P TCP/IP port used for connection.
socket or -S Socket file used for connection.
flush or -f Performs FLUSH TABLES before profiling begins If you
specify flush twice while also specifying a batch file of queries, FLUSH TABLES will be performed after each query.
help Displays help information and exits.
host or -h Specifies the hostname of mysqld used for query execution.
[no]innodb or -i Displays InnoDB table information Defaults to yes.
only or -n Only shows statistics for a list of queries or commands
(separated by commas).
password or -p The password used for connection to mysqld.
port or -P The TCP/IP port used for connections to mysqld.
separate or -s The script will print separate statistics for each query.
session The script uses SHOW SESSION STATUS and SHOW
SESSION VARIABLES.
setvars Used to set MySQL variables You can specify any variable
you want configured before query execution begins.
socket or -S Determines the Unix socket file used for a local connection.
continued
Trang 16TABLE 17-12 (continued )
tab or -t Output is displayed with tab-separated values.
user or -u Username that is used for connection to mysqld.
verbose or -v Determines the verbosity of the output If you specify
multiple times the output is more detailed.
verify or -r Verifies that nothing else is accessing mysqld.
version Outputs version information and exits.
Here is an example run ofmk-query-profilerwith very simple queries:
shell> mk-query-profiler askpass user=qa_user database=sbtest socket=/var/run/mysqld/mysqld.sock /home/bmurphy/queries.sql Enter password:
+ -+
+ -+
Overall stats _ Value
Data out of server 64889279
Table and index accesses Value
Trang 17The maatkit toolkit (which includes themk-query-profiler) is available atwww.
maatkit.org
mysqldumpslow
When profiling a server to determine bottlenecks, the slow query log provides a very useful way
to see which queries are causing problems and could possibly be optimized to improve queryexecution time While there are a modest number of programs available on the Internet to helpwith analyzing the slow query log, a script calledmysqldumpslow, which can be used for thisanalysis, is included in MySQL Server Table 17-13 lists the options formysqldumpslow
TABLE 17-13
mysqldumpslow Options
-a Does not abstract all numbers to ’N’ and strings to ’S’.
-d or debug Runs in debug mode.
-g STRING Performs a grep of the dump only including statements with string
STRING.
-h HOSTNAME Hostname of database server This is used to determine the name
of the slow query log (hostname-slow.log format).
help Displays help message and exits.
-i NAME Specifies the server instance name.
-l Includes lock time in the total query time.
-n NUM Abstracts all numbers in queries with at least NUM digits.
-r Reverses the sort order listing longest query run last instead of first.
-s ORDER Determines the sort order of the queries.
-t NUM Displays the top NUM queries.
-v or verbose Raises the verbosity level of output.
Trang 18With the-s(sort order) option there six possible values:t,at,l,r,c, ands.
■ Thetvalue sorts the query output by total execution time Total execution time is theaverage query execution time× the number of times the query was executed
■ Theatvalue sorts the query output by the average query execution time It is the defaultsorting method
■ Thelvalue sorts the query output by lock time
■ Thealvalue sorts the query output by lock time average
■ Thervalue sorts the query output by total rows
■ Thearvalue sorts the query output by average rows sent
■ Thecvalue sorts the query output by count
Here is an example of performing the sort by total execution time of the top five queries:
$ mysqldumpslow -s t -t 5 /mnt/mysql/logs/slowquery.log Reading mysql slow query log from /mnt/mysql/logs/slowquery.log Count: 3324 Time=9.79s (32533s) Lock=0.00s (0s) Rows=1.0 (3324), username@hostname
SELECT count(*) AS count_all FROM table_one WHERE (sweepstake_id =
N and user_id is null) Count: 1957 Time=11.26s (22028s) Lock=0.00s (0s) Rows=1.0 (1955), username@hostname
SELECT * FROM table_one WHERE (sweepstake_id = N and user_id is null) LIMIT N
Count: 279 Time=30.27s (8446s) Lock=0.00s (0s) Rows=0.6 (163), username@hostname
SELECT * FROM table_two WHERE (table_two.`id` = N) FOR UPDATE Count: 132 Time=43.59s (5754s) Lock=0.00s (0s) Rows=0.2 (23), username@hostname
SELECT * FROM table_one WHERE (table_one.`id` = N) FOR UPDATE Count: 901 Time=5.41s (4872s) Lock=0.02s (14s) Rows=1.0 (897), username@hostname
SELECT * FROM table_three WHERE (table_three.`value`=’S’) LIMIT N
Knowing that these five queries spent more time executing (total execution time) than all theother queries, you can concentrate your time on optimizing these queries Query optimization
is covered in detail in Chapter 18
Trang 19Capacity Planning
Capacity planning, as it relates to information technology, is the process of determining the
computing infrastructure requirements needed by a company to meet changing demands forproducts or services The ultimate goal of benchmarking and profiling is to measure the capacity
of a server If you know through benchmarking that a server can operate at a peak capacity of
X performance units and you know through profiling that a production server is operating at a level of Y performance units, then you know that you have a current excess capacity level of X –
Y performance units When the production server is operating at a level of X production units,
then you have no more room for growth
If you have been profiling production servers over a period of time, you can develop trendingpatterns and, through simple extrapolation, know how much time you have before a produc-tion server reaches full capacity In many cases, this is all the capacity planning needed (at leastwhen it comes to database servers!) If you know that your current servers will reach capacity in
9 to 12 months, it will be much easier to plan for increased capacity by adding more servers or
upgrading the current servers, rather than being surprised when your servers suddenly bogs down
and performs extremely poorly because it is overloaded
Unfortunately, many database administrators feel that they are too busy to either measure theperformance of servers or do any type of capacity planning In the end, this costs you more timeand effort when you have to reacting to a situation where your servers reach capacity instead ofplanning ahead
In this chapter, we covered the following topics:
■ Benchmarkingmysqld
■ mysqlslap
■ MyBench
■ SysBench
Trang 23Index Tuning
IN THIS CHAPTERAnalyzing queries using EXPLAIN
Using EXPLAIN on non-SELECT statements
Using other query analysis tools
Optimizing queries
‘‘The database is slow!’’
A DBA will hear this over and over during his or her career Althoughthere are times when performance can be tuned best by changing serverparameters, most of the time database slowness, it is because the:
■ The query cache is not being utilized properly (see Chapter 12 fortroubleshooting)
■ The query contains subqueries (MySQL Server 5.1) or unoptimizedsubqueries (MySQL Server 6.0) See the companion website atwww.wiley.com/go/mysqladminbiblefor information abouthow to avoid subqueries
■ The table contains a large amount of unnecessary data
■ The table is fragmented
■ The schema was not designed for the queries being run
■ The queries being run do not take into consideration the schemadesign
■ Tables have no indexes that are appropriate for the query
The reason for the disparity between the schema and queries may be that
a developer is not familiar with MySQL, a DBA made assumptions aboutdatabase usage, or the schema and queries were in sync at one point, butthe data and/or application has grown
A database schema is always a work in progress; as long as differentqueries are being written or the data inside a schema is changing, it isnecessary to reanalyze both the schema and queries
Trang 24The larger issues of benchmarking and profiling are covered in Chapter 17, ‘‘MeasuringPerformance’’; these techniques are used to identify the queries you need to analyze Once youhave identified queries causing problems, the information in this chapter will help you analyzeand tune queries and, where appropriate, the database schema.
While there can be performance improvements done by tuning a server (Chapter 10), larly to the needs of your storage engine (Chapter 11), overwhelmingly the reason that a query
particu-is slow particu-is because of the data in the table, the schema, and the query itself
Using EXPLAIN
The most widely used query analysis tool isEXPLAIN, an SQL extension.EXPLAIN select_statementshows information about howselect_statementwill likely beexecuted
This information includes:
■ How many tables are involved
■ How the tables are joined
■ How the data is looked up
■ If there are subqueries
■ If there are unions
■ IfDISTINCTis used
■ If aWHEREclause is used
■ If a temporary table is used
■ Possible indexes used
■ Actual indexes used
■ Length of actual indexes used
■ Approximate number of records returned
■ If sorting requires an extra pass through the dataThe information is known as the query execution plan, and is also referred to as theEXPLAINplan
EXPLAIN plan basics
EXPLAINis used in front of aSELECTstatement, and returns 10 fields:
mysql> EXPLAIN SELECT return_date -> FROM rental WHERE rental_id = 13534\G
Trang 25*************************** 1 row ***************************
id: 1 select_type: SIMPLE table: rental type: const possible_keys: PRIMARY
key: PRIMARY key_len: 4 ref: const rows: 1 Extra:
1 row in set (0.00 sec)The first field,id, is a sequential identifier, which is different for each row Each row represents
a physical table, subquery, temporary table, or derived table In this simple example, there isonly one table being queried, so there is only one row, with anidof 1 Tables are returned injoin queue order, which means that a table in row 1 is used first, then joined to the table in row
2, and so on
When EXPLAIN involves a view, returned rows correspond to the tables, subqueries, unions, and temporary tables used in the view definition There is no row returned for the view itself.
The second field,select_type, is the type of SELECTrepresented by the row The third field,table, shows the table alias that the row refers to Often, theselect_typewill beSIMPLE,
as it is in our example When usingEXPLAINon aUNIONquery, theselect_typeof the firstrow isPRIMARY Other rows have aselect_typeofUNION, and there is a final row represent-ing the action of performing theUNIONon the result sets of the previous queries For example,here is anEXPLAINplan for a simpleUNION, getting the first names for all staff and customers:
mysql> EXPLAIN SELECT first_name FROM staff UNION SELECT first_name FROM customer\G
*************************** 1 row ***************************
id: 1 select_type: PRIMARY table: staff type: ALL possible_keys: NULL
key: NULL key_len: NULL ref: NULL rows: 1 Extra:
*************************** 2 row ***************************
id: 2 select_type: UNION table: customer type: ALL