Pro MySQL experts voice in open source phần 10 ppt

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (562.16 KB, 76 trang )

Solutions
The following are a few ways of discovering the cause of a broken MySQL connection:
•To verify that it was a connection problem, reconnect and issue the statement again.
If the statement runs successfully, you probably encountered a timeout.
•If the connection is broken when you run the query a second time, check the value
of your max-allowed-packet setting. You can also look in the error log to see if a
Packet too large message is logged. If so, increase the max-allowed-packet value.
• Check with your database administrator to see if he killed your connection.
■Note The database administrator should immediately contact users with a notification that their connec-
tion was causing a problem and was killed, and help them work through the problem.
•If you don’t have a problem with the packet size, carefully examine the syntax of your
query. MySQL will sometimes close the connection if the query syntax is incorrect.
Make sure all of your join fields are specified. You may want to reduce the complexity
of the query, and gradually build it piece by piece to get back to the original complex
query.
•If, in building a query, you find that some combination of valid SQL syntax generates
this error, you may have stumbled into a MySQL bug (rare, but possible). See the “How
to Report MySQL Bugs” section later in this chapter for information about finding and
reporting bugs to MySQL AB.
For more information, refer to and
/>Troubleshooting Start, Restart, and Shutdown Issues
In this section, we’ll discuss common problems related to starting and shutting down the
server properly, including the following:
•Determining whether the server crashed
•Problems starting the MySQL server
•Problems stopping the MySQL server
•Unexpected restarts
■Note While MySQL aims to make every server installation a bump-free and quick process, you may run
into trouble when installing or upgrading your server. See Chapter 14 for information that will help if you
have problems installing or upgrading a MySQL database.
CHAPTER 20 ■ TROUBLESHOOTING 661

505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 661
Did the Server Crash?
Depending on the message you get from the client, you may not be sure if the database server
restarted or if you just had an issue with a client or a query. It is sometimes confusing trying
to determine how significant the event was. Although a client connection getting closed is
important to resolve, most administrators would consider a server restart far more serious.
Being aware of where the problem occurred is important.
You have several ways to determine when the server last restarted. One way is to use the
mysqladmin version command and check the uptime to determine if the server has recently
restarted. Output from this command is shown in Listing 20-7. As you can see on the Uptime
line, the server has been up for ten days, meaning that, in this example, the message you just
got from the client was not because the server restarted.
Listing 20-7. Output from mysqladmin version
# mysqladmin version
mysqladmin Ver 8.41 Distrib 5.0.6-beta, for unknown-linux-gnu on x86_64
Server version 5.0.6-beta-max-log
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /tmp/mysql.sock
Uptime: 10 days 21 hours 58 min 21 sec
Threads: 1 Questions: 858 Slow queries: 0 Opens: 0 Flush tables: 1
Open tables: 3 Queries per second avg: 0.001
You can also get the uptime in seconds from within the MySQL shell, by using the
SHOW VARIABLES LIKE 'uptime' command. The output of this command is shown in Listing 20-8.
Listing 20-8. Uptime from MySQL Client
mysql> SHOW VARIABLES like 'uptime';
+ + +
| Variable_name | Value |
+ + +
| Uptime | 84472 |

+ + +
1 row in set (0.00 sec)
Another method for seeing if the database has recently restarted, and to get the history
of activity over time, is to check the error log. Listing 20-9 shows the output of the log with an
egrep for messages that indicate the server has stopped, started, or restarted. If you find unex-
plained entries in this output, you should look more closely at the error log and general query
log to compare database activity with the unexplained server restarts to determine what might
be the cause of the problem.
CHAPTER 20 ■ TROUBLESHOOTING662
505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 662
Listing 20-9. egrep of Error Log
shell> egrep "(ended|started|restarted)" promysql.err
050501 13:16:10 mysqld started
050501 15:51:32 mysqld ended
050501 15:51:33 mysqld started
050502 15:41:29 mysqld ended
050502 15:41:31 mysqld started
050502 15:41:43 mysqld ended
050502 16:02:04 mysqld started
050502 16:04:50 mysqld ended
050502 16:05:03 mysqld started
050505 17:48:40 mysqld ended
050505 17:54:07 mysqld started
For more information about the mysqld_safe startup script, see />doc/mysql/en/mysqld-safe.html. For what to do if MySQL keeps crashing, refer to http://
dev.mysql.com/doc/mysql/en/crashing.html.
Problems Starting MySQL Server
Have you ever started the MySQL server only to find that, before you can connect, the MySQL
server daemon ended? In MySQL version 5.0.4, the mysql.server script changed a bit to pre-
vent the server from indicating it started up only to shut right back down. As of MySQL 5.0.4,
when you issue the start command, you wait until the database has started, and then get a

success message:
/etc/init.d/mysql start
Starting MySQL SUCCESS!
Evidence of the Problem
The most common way to find that your server won’t start is to wait in suspense as the server
startup process runs, and then see it finally indicates an error occurred:
/etc/init.d/mysql start
Starting MySQL ERROR!
If you aren’t using the startup script, the common indicator is the mysql ended message
in the logs or on the console where the server was started. Also, starting the server using
the MySQL binary itself will keep the process and messages in the forefront, as shown in
Listing 20-10.
CHAPTER 20 ■ TROUBLESHOOTING 663
505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 663
Listing 20-10. Running MySQL Without a Startup Script
./bin/mysqld
050430 14:56:32 [Warning] Can't create test file /data/mysql/promysql.lower-test
./bin/mysqld: Can't change dir to '/data/mysql/' (Errcode: 2)
050430 14:56:32 [ERROR] Aborting
Seeing the error about /data/mysql shown in Listing 20-10, you would check what’s going
on in the /data/mysql directory where your data files are stored. You might learn that the data
directory is not properly mounted.
Solutions
Following are some steps to take when you have problems starting up MySQL:
• Check to see if MySQL is already running, or if the network port you are using for
MySQL is being used by another process.
• Check the error logs to determine if any abnormal event was logged.
•Be sure your directories and data file permissions are set for the MySQL user and group.
•If the startup fails with an unknown option, fix the offending option.
• Check to see if there are missing data or log directories specified in the configuration file.

•If all of your existing options seem correct and your directories are fine, but you still
are not seeing any log information, start MySQL using just the daemon itself with
./bin/mysqld, and see what kind of output is generated.
For more information about the MySQL startup script, see />mysql/en/mysql-server.html.
Problems Stopping MySQL Server
In rare cases, you may find that you cannot seem to stop the MySQL server. Most often, this is
related to a thread being busy in the database.
Evidence of the Problem
You’ll see this problem when you attempt to stop the MySQL server:
sudo /etc/init.d/mysql stop
And instead of the typical, few seconds to stop the database, the wait continues until your
database indicates it can’t be stopped:
Killing mysqld with pid 32441
Wait for mysqld to exit gave up waiting!
Or, with the MySQL 5.0.4 and later mysql.server script, you’ll see that the stop process
ends in an error:
/etc/init.d/mysql stop
Shutting down MySQL ERROR!
CHAPTER 20 ■ TROUBLESHOOTING664
505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 664
Solutions
Here are a few things to check and do if you are having a problem shutting down MySQL:
•You may have a thread that is busy and is preventing the server from stopping. Use the
SHOW PROCESSLIST command to identify queries that are in progress. Killing the connec-
tion may be what’s required to stop MySQL.
•Before stopping the database, stop resources (like Apache) that maintain connections
to MySQL that could prevent the database from stopping.
•Is the MySQL server actually running? Look at processes and verify that MySQL is run-
ning. If the PID file exists, the error will come back even if the process isn’t running. If
your server stopped abnormally and didn’t have a chance to remove the PID file, it will

attempt to shut down as if it were running.
■Caution When you’re having issues with shutting down a server, you may be tempted to use the operat-
ing system to force MySQL to exit. If MySQL won't shut down because it's busy writing data and you force it
to, you may end up with corrupt or missing data. Use the operating system-level process termination com-
mand or tool only as a last resort.
For more information, see />Problems with Unexpected Restarts
A server unexpectedly restarting can lead to a lot of stress. If you are in an environment where
every second counts, not knowing when the next server restart is going to happen may be unac-
ceptable. For other database uses, unexpected restarts are less damaging, but still unnerving. If
you have experienced unexpected restarts, you’ll want to know what caused them and how to
prevent them in the future.
Evidence of the Problem
Although a restart by mysqld_safe happens quickly, it is easily noticed by an application under
heavy usage when connections can’t be made for the small amount of time the server is down
during the restart. If a restart goes unnoticed, or to figure out the exact timing, you can see the
entry (or entries) by doing a grep "restarted" host.err.
Solutions
If you have problems with unexpected server restarts, the following items may help you resolve
the problem:
•Not having enough memory can cause unexpected restarts. This can happen if MySQL
needs more memory than is physically available on the server or another process is
consuming a lot of memory. If you have a system that monitors your server’s resources,
check to see whether the low amount of memory available correlates to the times when
the MySQL server restarted.
CHAPTER 20 ■ TROUBLESHOOTING 665
505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 665
•Server restarts are a sign of corruption in the database tables. You should go through
the steps to check the status of your tables and repair them if necessary. The next sec-
tion provides more information about data corruption.
•Perform troubleshooting tasks on the operating system and hardware. A defective disk,

damaged RAID controller, or faulty RAM can affect MySQL’s ability to function and may
cause the database to restart during certain failures.
• Check the following MySQL documentation:
• What to do if MySQL keeps crashing: />reproduceable-test-case.html
•Table maintenance: />• Check MyISAM tables: />•Repair MyISAM tables: />Resolving Data Corruption
As hard as MySQL developers work to perfect the database software, and database administra-
tors work to keep their systems protected, data corruption does occur. The MySQL development
team takes data corruption very seriously and provides a set of instructions to follow to create a
reproducible bug that will allow them to identify where the corruption is happening.
Evidence of the Problem
The corrupted data files often show up in the form of a server crash or unexpected restart.
They cause queries to fail or to return unexpected results (or no results). A more proactive
approach for databases using the MyISAM storage engine is to regularly run the mysqlcheck
script to determine if any tables are corrupted.
The following are some reasons that you might experience data file corruption:
• The server was killed in the middle of an update.
•A bug caused MySQL to stop while writing to disk.
• An external program is manipulating the data files.
•Multiple servers are pointed to the same data files.
•A corrupted data file caused the server to act improperly and corrupt other data.
•A storage engine bug caused bad data to be written.
• The operating system, hardware, or disks may be faulty.
CHAPTER 20 ■ TROUBLESHOOTING666
505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 666
Solutions
If you encounter a corrupt data file, here are some areas to look into:
•Be sure you have backups of your data. Yes, once you’ve discovered there is corruption
it may be too late, but we hope you’ve had enough foresight to create regular backups
(see Chapter 17 for details about backing up MySQL).
•If you are using MyISAM tables, run the mysqlcheck or myisamchk script to repair the table.

•If you can still get your database to run and use the table, do a mysqldump of the table,
DROP the table, and then import the data from the dump. (Chapter 17 describes how to
use mysqldump.)
•Follow MySQL’s steps to create a repeatable situation and contact MySQL with the nec-
essary information. You can find these steps at />reproduceable-test-case.html.
You can refer to the MySQL documentation for checking and recovering MyISAM tables,
at and />doc/mysql/en/crash-recovery.html, respectively.
How to Report MySQL Bugs
It is possible that, in your use of MySQL, you encounter a bug. MySQL doesn’t release software
marked as production-ready until all known fatal bugs are resolved. MySQL defines a fatal bug
as one that causes the server to crash under normal use, gives the wrong answer for a normal
query, or contains a security problem. That being said, there is an active bug-tracking system
that allows database users to submit bugs and track their status as they go through the system.
If you think you’ve found a bug, follow the steps outlined in the MySQL documentation
for submitting a bug report ( This
involves the following steps:
•Make sure it’s a repeatable bug ( />test-case.html).
•Search the existing documentation and mailing lists to see if there is a resolution.
•Search through the bug reports to see if it has been reported
( />•Finally, submit the bug report with information about your environment and how to
duplicate the bug.
The MySQL team follows the bug-tracking system very closely and usually gets to work on
a bug report within just a few hours.
CHAPTER 20 ■ TROUBLESHOOTING 667
505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 667
Support Options
A chapter on troubleshooting wouldn’t be complete without mentioning support options.
Each organization has different needs, and you have a wide spectrum of options when you’re
looking for support for your MySQL installation. What matches your needs will depend on
what assistance you require and when you require it.

Here are some support options:
Mailing lists: If you have some expertise with MySQL, and your troubleshooting priorities
allow you time to search and post, you can get a lot of information and help from the
MySQL mailing lists. The collective group of people who participate have a great deal of
expertise, and response time is typically pretty good (provided you have good manners).
Even if you have a critical problem that is happening in real time, it’s still worth trying out
a mailing list to get help exploring the issue and formulating a strategy to resolve it. There
are several MySQL mailing lists. Unless you have a specific question about a particular
piece of MySQL that has its own mailing list, the general user mailing list is the place to
go. For a list of all of MySQL mailing lists, along with the list archives and instructions for
subscription, visit />Consultants: If you are running an instance of MySQL, but don’t have the time, interest, or
ability to resolve a problem, a consultant may be the right person to step in. A web search
for “MySQL consultant” brings up hundreds of links leading to people who have experi-
ence with MySQL and are looking for opportunities to apply their knowledge and
experience.
Help from MySQL AB: If you are looking for MySQL expertise, why not turn to the folks
who are building the database? MySQL AB offers several consulting packages, including a
one-day rapid response service for urgent needs (a certified consultant will work with you
on troubleshooting, performance, architecture, or any of your MySQL needs). Another
option from MySQL AB is the MySQL Network ( a serv-
ice that gives you access to production support and MySQL developers to help solve your
unique issues. The MySQL Network also provides certified releases of the MySQL database.
Summary
Troubleshooting a database server can be a stressful experience, especially if the problem is
occurring in your production environment and affecting the availability of your application.
A good database administrator is familiar with the details of MySQL and knows exactly what
to do when a situation arises. This includes having a thorough knowledge of how to use the
troubleshooting tools and where to look for answers.
We spent a significant portion of the chapter discussing the various tools and logs that are
the foundation for dealing with specific problems. We then went through a number of differ-

ent common problems and gave details on possible causes and solutions. Our goal was to
provide some detailed information, as well as to show you examples of the methodology for
working through problems.
As you combine the knowledge of MySQL administration with the honing of your real-
time problem-solving skills, you will become more capable of surviving a problem in your
database without unnecessary stress and wasted time. This, in turn, will please the users of
your database, as well as your manager, customers, and clients.
CHAPTER 20 ■ TROUBLESHOOTING668
505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 668
MySQL Data Dictionary
In this chapter, we’ll be taking a closer look at a feature of MySQL 5 that’s receiving consider-
able attention. As of version 5.0.2, the INFORMATION_SCHEMA virtual database is available, which
offers a standardized way of reading meta information about the database server and its
schemas. In this chapter, we’ll examine what exactly the INFORMATION_SCHEMA data store is,
how you can use it, and what information is contained inside it.
Before we go further, we want to discuss a few terms used in this chapter. The discussion
of a database server’s meta information commonly involves the following terms:
• metadata
• data dictionary or system catalog
• INFORMATION_SCHEMA
The definition of metadata is simply data about other data. Metadata describes or sum-
marizes another piece of data. Examples of metadata include the number of rows in a table,
the type of index structure used on a set of columns, or the statement used to create a stored
procedure. Each of these pieces of data describes another piece of data or structure.
All major database vendors have a repository, or container, for metadata, but different
database vendors refer to this repository differently. The two most common terms, however,
are data dictionary and system catalog. We consider them synonymous, but when referring to
the metadata repository, we’ll use the term data dictionary.
The term INFORMATION_SCHEMA describes the ANSI standard interface to the database
server’s metadata. The INFORMATION_SCHEMA is not an actual schema (database), but the data

contained inside this virtual database can be accessed just like any other database on the
server. In this way, the INFORMATION_SCHEMA interface acts as a standardizing component for
accessing information about the database server and its actual schema. The “tables” inside
this virtual database aren’t tables at all, but rather table-like data that is pulled from a variety
of sources, including the underlying mysql system database, and the MySQL server system
variables and counters.
In this way, the INFORMATION_SCHEMA tables are more like views than tables. If you’re coming
from a Microsoft SQL Server background, you’ll recognize this concept, as the INFORMATION_SCHEMA
supported by Microsoft SQL Server are views that pull actual data from the Microsoft SQL Server
system tables, such as sys_objects and sys_indexes. INFORMATION_SCHEMA views are read-only,
partly because the data contained in the INFORMATION_SCHEMA views isn’t contained in a single
location, but instead pulled from the storage areas noted earlier.
669
CHAPTER 21
■ ■ ■
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 669
In this chapter, we’ll be looking at the following topics related to the new INFORMATION_
SCHEMA feature of MySQL 5:
•Benefits of a standardized interface
• The INFORMATION_SCHEMA views
•Examples of usage
Benefits of a Standardized Interface
Before we get into the specific tables that comprise the MySQL Data Dictionary, we want you
to understand why the data dictionary has been added as a feature to the MySQL 5 source
code. For those of you without much experience with MySQL’s SHOW commands, the transition
to using the INFORMATION_SCHEMA database might take some getting used to, but we highly rec-
ommend taking the time to do so.
There are three main advantages to the INFORMATION_SCHEMA interface versus the SHOW
commands:
•Adherence to standards

•Using SELECT to retrieve metadata
•More information than SHOW commands
Adherence to Standards
MySQL’s SHOW commands are proprietary and not standards-compliant. By contrast, the
INFORMATION_SCHEMA interface is a standard outlined by ANSI/ISO as part of the SQL-99 and
SQL:2003 standards.
One advantage to complying with these standards is that applications that rely on querying
for metadata—for example, a monitoring application—can be written in a portable fashion. The
databases supporting INFORMATION_SCHEMA views are MySQL, Microsoft SQL Server, and, to some
extent, IBM’s DB2 database. Hopefully, in the future, all major database vendors will move to full
compliance, and application code can be truly vendor-agnostic. Having metadata queries written
for the INFORMATION_SCHEMA interface is a proactive stance for future portability needs.
To adhere completely to the SQL standard, MySQL’s implementation of the INFORMATION_
SCHEMA shows columns for which MySQL has no equivalent data. For these columns—for
instance, the INFORMATION_SCHEMA.TABLES.TABLE_CATALOG column—MySQL simply displays
a NULL value, because MySQL has no concept of a database “catalog.” In addition, MySQL
displays certain additional data pieces in the INFORMATION_SCHEMA output where MySQL stores
nonstandard or extension information. This is done to provide complete equivalency to the
MySQL SHOW commands. We’ll detail later where the MySQL implementation diverges from
the ANSI standard.
Using SELECT to Retrieve Metadata
Perhaps the best reason to use the INFORMATION_SCHEMA views is that you can access metadata
through your standard SQL SELECT statements. Instead of various SHOW commands—such as
SHOW TABLES, SHOW FULL COLUMNS, and so on—you access the data through the old familiar
SELECT statement.
CHAPTER 21 ■ MYSQL DATA DICTIONARY670
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 670
This means you’ll have to learn the INFORMATION_SCHEMA views, to ensure you know where
to look for information. However, the advantage to using SELECT here is that you don’t have
to learn any new syntax to read information from the INFORMATION_SCHEMA. You can use the

various joins you learned in Chapter 7 to present views of related metadata in a way that was
impossible before. Because the INFORMATION_SCHEMA is accessible through standard SQL state-
ments, you can operate on the data sets returned from a query on the INFORMATION_SCHEMA
tables as you would any other SQL statement. This makes it easy to construct complex SELECT
statements that use the information in the INFORMATION_SCHEMA views like any other table in
your other databases.
More Information than SHOW Commands
As you’ll see in the following section, the INFORMATION_SCHEMA offers you more detailed infor-
mation than equivalent SHOW commands. In some cases, a single SELECT statement against the
INFORMATION_SCHEMA views can output more than what multiple SHOW commands could provide.
■Note To use the INFORMATION_SCHEMA views, the user must be granted privileges on the object that
the view represents. Therefore, although no special privilege is needed to issue a
SELECT against the
INFORMATION_SCHEMA, the results of certain SELECTs on the metadata repository depend on which
schema, tables, or columns the user has been granted access to.
The INFORMATION_SCHEMA Views
In this section, we cover each of the views available under the INFORMATION_SCHEMA, and out-
line which columns returned from the view equate to the prior SHOW command, if one existed.
We use simple examples in this section to highlight the information available from the follow-
ing INFORMATION_SCHEMA views:
• INFORMATION_SCHEMA.SCHEMATA
• INFORMATION_SCHEMA.TABLES
• INFORMATION_SCHEMA.TABLE_CONSTRAINTS
• INFORMATION_SCHEMA.COLUMNS
• INFORMATION_SCHEMA.KEY_COLUMN_USAGE
• INFORMATION_SCHEMA.STATISTICS
• INFORMATION_SCHEMA.ROUTINES
• INFORMATION_SCHEMA.VIEWS
• INFORMATION_SCHEMA.CHARACTER_SETS
• INFORMATION_SCHEMA.COLLATIONS

• INFORMATION_SCHEMA.COLLATION_CHARACTER_SET_APPLICABILITY
CHAPTER 21 ■ MYSQL DATA DICTIONARY 671
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 671
• INFORMATION_SCHEMA.SCHEMA_PRIVILEGES
• INFORMATION_SCHEMA.USER_PRIVILEGES
• INFORMATION_SCHEMA.TABLE_PRIVILEGES
• INFORMATION_SCHEMA.COLUMN_PRIVILEGES
■Note Plans are under way to add more views to INFORMATION_SCHEMA. Notably, the following views are
planned for release:
TRIGGERS, PARAMETERS, and REFERENTIAL_CONSTRAINTS. As we go to press, details
about these views are still limited. Check the MySQL documentation for the latest
INFORMATION_SCHEMA
view lists: />It’s worth noting again here that the results displayed from the INFORMATION_SCHEMA views
are specific to the user logged in. That means that only schemata, tables, or columns to which
the user has been granted access appear in the resultsets.
In the following subsections, for each INFORMATION_SCHEMA view, we show you the DESCRIBE
of the view, a simple SELECT on the view, then in a bulleted list, we define what each of the
output columns contains. For each section, you’ll see a note block detailing which SHOW
commands, if any, correspond to the new INFORMATION_SCHEMA view.
Instead of arranging the views in alphabetical order, we’ve ordered them in groups that
most closely relate to one another. For instance, we’ve grouped the privileges views together
and the character set and collation views together. This order will help give you an idea of the
relationship of the view data.
In the following sections, fields that are not part of the ANSI standard appear in italics to
denote that the column is a MySQL-specific data element. These fields have been left in the
INFORMATION_SCHEMA outputs as an extension to allow equivalent output to some SHOW com-
mands. If you’re attempting to create cross-platform portable SQL code, please be aware of
these extension fields.
■Note Two quick notes before we get into the views. First, some of the following examples were issued
against the

test.http_auth table created and used in Chapter 6. If you get an empty resultset for some of
the examples, either follow along in the reading, or refer to Chapter 6 for creation of the
http_auth table in
the
test database.
Second, depending on your operating system and version of MySQL, you may notice slight differences in some
of the output. Notably, depending on the version of MySQL you use, a VARCHAR(4096) column displayed in
results in this chapter may appear as
VARCHAR(4095), or in a Windows environment, VARCHAR(512).These
are minor discrepancies, and as the data dictionary features of MySQL 5 are an evolving work, these data types
may have changed by the time we go to print.
CHAPTER 21 ■ MYSQL DATA DICTIONARY672
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 672
INFORMATION_SCHEMA.SCHEMATA
The SCHEMATA view shows information about the databases on the server. Listing 21-1 shows
the columns displayed by the view.
Listing 21-1. INFORMATION_SCHEMA.SCHEMATA
mysql> DESCRIBE INFORMATION_SCHEMA.SCHEMATA;
+ + + + + + +
| Field | Type | Null | Key | Default | Extra |
+ + + + + + +
| CATALOG_NAME | varchar(4096) | YES | | NULL | |
| SCHEMA_NAME | varchar(64) | NO | | | |
| DEFAULT_CHARACTER_SET_NAME | varchar(64) | NO | | | |
| SQL_PATH | varchar(4096) | YES | | NULL | |
+ + + + + + +
4 rows in set (0.04 sec)
mysql> SELECT * FROM INFORMATION_SCHEMA.SCHEMATA;
+ + + + +
| CATALOG_NAME | SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | SQL_PATH |

+ + + + +
| NULL | information_schema | utf8 | NULL |
| NULL | mysql | latin1 | NULL |
| NULL | test | latin1 | NULL |
+ + + + +
3 rows in set (0.02 sec)
The fields contained in INFORMATION_SCHEMA.SCHEMATA are as follows:
• CATALOG_NAME: This field will always be NULL, as MySQL doesn’t have any concept of a
catalog. It’s provided to maintain the ANSI standard output.
• SCHEMA_NAME: This is the name of the database.
• DEFAULT_CHARACTER_SET_NAME: This is the name of the default character set for the data-
base. We discuss the INFORMATION_SCHEMA.CHARACTER_SETS view later in the chapter.
• SQL_PATH: This field will always be NULL. MySQL doesn’t use this value to “find” the files
associated with the database. It’s included for compatibility with the ANSI standard.
Although the SCHEMATA view isn’t the most useful of the INFORMATION_SCHEMA views, it does
contain the database’s default character set, while the corresponding SHOW DATABASES command
doesn’t.
■Note The SHOW DATABASES command is the closest command to SELECT * FROM INFORMATION_
SCHEMA.SCHEMATA.
CHAPTER 21 ■ MYSQL DATA DICTIONARY 673
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 673
INFORMATION_SCHEMA.TABLES
The INFORMATION_SCHEMA.TABLES view stores information about the database tables on the
server. Listing 21-2 shows the DESCRIBE and a simple SELECT from the view.
Listing 21-2. INFORMATION_SCHEMA.TABLES
mysql> DESCRIBE INFORMATION_SCHEMA.TABLES;
+ + + + + + +
| Field | Type | Null | Key | Default | Extra |
+ + + + + + +
| TABLE_CATALOG | varchar(4096) | YES | | NULL | |

VERSION: 9
ROW_FORMAT: Fixed
TABLE_ROWS: 90000
AVG_ROW_LENGTH: 59
DATA_LENGTH: 5310000
CHAPTER 21 ■ MYSQL DATA DICTIONARY674
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 674
MAX_DATA_LENGTH: 253403070463
INDEX_LENGTH: 3716096
DATA_FREE: 0
AUTO_INCREMENT: NULL
CREATE_TIME: 2005-03-08 23:25:28
UPDATE_TIME: 2005-03-08 23:29:38
CHECK_TIME: NULL
TABLE_COLLATION: latin1_swedish_ci
CHECKSUM: NULL
CREATE_OPTIONS:
TABLE_COMMENT:
1 row in set (0.00 sec)
The fields contained in INFORMATION_SCHEMA.TABLES are as follows:
• TABLE_CATALOG: Again, will always be NULL. Shown for compatibility purposes.
• TABLE_SCHEMA: The name of the database to which this table belongs.
• TABLE_NAME: The name of the table.
• TABLE_TYPE: Either BASE TABLE, TEMPORARY, or VIEW. Those entries having a VIEW value
also appear in INFORMATION_SCHEMA.VIEWS. More details about this view come later in
the chapter.
• ENGINE: The storage engine handling this table’s data.
• VERSION: The internal versioning of the table’s .frm file. Indicates how many times the
table’s definition has changed.
• ROW_FORMAT: Either FIXED, COMPRESSED, or DYNAMIC. Indicates the format of table rows.

See Chapter 5 for more details on the difference between the row formats.
• TABLE_ROWS: Shows the number of rows in a table.
• AVG_ROW_LENGTH: Shows the average length, in bytes, of the table’s rows.
• DATA_LENGTH: Shows the total length, in bytes, of the table’s data.
• MAX_DATA_LENGTH: Shows the maximum storage length, in bytes, that the table’s data can
consume.
• INDEX_LENGTH: Shows the total length, in bytes, of the table’s indexes.
• DATA_FREE: Shows the number of bytes that have been allocated to the table’s data, but
that haven’t yet been filled with table data.
• AUTO_INCREMENT: Shows the next integer number to be used on the table’s AUTO_INCREMENT
column, or NULL if no such sequence is used on the table.
• CREATE_TIME: Timestamp of the table’s initial creation.
• UPDATE_TIME: Timestamp of the last ALTER TABLE command on this table. If there have
been no ALTER TABLE commands, then shows the same timestamp as CREATE_TIME.
CHAPTER 21 ■ MYSQL DATA DICTIONARY 675
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 675
• CHECK_TIME: Timestamp of the last time a table check was performed on the table, or
NULL if the table has never been checked for consistency.
• TABLE_COLLATION: Shows the table’s default character set and collation combination.
See INFORMATION_SCHEMA.COLLATION_CHARACTER_SET_APPLICABILITY for more details.
• CHECKSUM: Internal live checksum for the table, or NULL if none is available.
• CREATE_OPTIONS: Shows any options used at table creation, or nothing if none has
been used.
• TABLE_COMMENT: Shows any comment used during table creation.
Clearly, the INFORMATION_SCHEMA.TABLES view has a wealth of useful information about
the database tables on your MySQL server. The vast majority of the columns, as you may well
have noticed, are extension fields that MySQL has included to provide compatibility with the
SHOW TABLE STATUS command.
■Note The SHOW TABLE STATUS command displays most of the information that a SELECT * FROM ➥
INFORMATION_SCHEMA.TABLES would output.

CONSTRAINT_SCHEMA: test
CONSTRAINT_NAME: PRIMARY
TABLE_SCHEMA: test
TABLE_NAME: http_auth_idb
CONSTRAINT_TYPE: PRIMARY KEY
2 rows in set (0.31 sec)
The fields contained in INFORMATION_SCHEMA.TABLE_CONSTRAINTS are as follows:
• CONSTRAINT_CATALOG: Again, always NULL.
• CONSTRAINT_SCHEMA: Name of the database in which the table constraint (index) resides.
This is always the same as the value of TABLE_SCHEMA.
• CONSTRAINT_NAME: Name of the constraint.
• TABLE_SCHEMA: Name of the database for the table on which the index is built.
• TABLE_NAME: Name of the table on which the index is built.
• CONSTRAINT_TYPE: Either PRIMARY KEY, FOREIGN KEY, or UNIQUE, depending on what engine
is handling the table, and how the key was referenced in a CREATE TABLE statement. In the
future, MyISAM tables will fully support FOREIGN KEY constraints. Currently, you only see
FOREIGN KEY pop up when an InnoDB table is referenced during create time.
■Tip The SHOW INDEX command most closely resembles the output from INFORMATION_SCHEMA.
TABLE_CONSTRAINTS
. The CONSTRAINT_TYPE column contains similar information to the KEY_NAME
column returned by SHOW INDEX for entries with a NON_UNIQUE value of 0.
CHAPTER 21 ■ MYSQL DATA DICTIONARY 677
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 677
INFORMATION_SCHEMA.COLUMNS
The INFORMATION_SCHEMA.COLUMNS view shows detailed information about the columns con-
tained in the server’s database tables. Listing 21-4 shows a DESCRIBE and a simple SELECT
from the view.
Listing 21-4. INFORMATION_SCHEMA.COLUMNS
mysql> DESCRIBE INFORMATION_SCHEMA.COLUMNS;
+ + + + + + +

ORDINAL_POSITION: 1
COLUMN_DEFAULT:
IS_NULLABLE: NO
DATA_TYPE: char
CHARACTER_MAXIMUM_LENGTH: 25
CHARACTER_OCTET_LENGTH: 25
CHAPTER 21 ■ MYSQL DATA DICTIONARY678
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 678
NUMERIC_PRECISION: NULL
NUMERIC_SCALE: NULL
CHARACTER_SET_NAME: latin1
COLLATION_NAME: latin1_swedish_ci
COLUMN_TYPE: char(25)
COLUMN_KEY: PRI
EXTRA:
PRIVILEGES: select,insert,update,references
COLUMN_COMMENT:
… omitted
*************************** 4. row ***************************
TABLE_CATALOG: NULL
TABLE_SCHEMA: test
TABLE_NAME: http_auth
COLUMN_NAME: gid
ORDINAL_POSITION: 4
COLUMN_DEFAULT: 0
IS_NULLABLE: NO
DATA_TYPE: int
CHARACTER_MAXIMUM_LENGTH: 11
CHARACTER_OCTET_LENGTH: 11
NUMERIC_PRECISION: 11

NUMERIC_SCALE: 0
CHARACTER_SET_NAME: NULL
COLLATION_NAME: NULL
COLUMN_TYPE: int(11)
COLUMN_KEY:
EXTRA:
PRIVILEGES: select,insert,update,references
COLUMN_COMMENT:
4 rows in set (0.01 sec)
The fields contained in INFORMATION_SCHEMA.COLUMNS are as follows:
• TABLE_CATALOG: Again, always NULL.
• TABLE_SCHEMA: Name of the database.
• TABLE_NAME: Name of the database table or view.
• COLUMN_NAME: Name of the column.
• ORDINAL_POSITION: Starting with 1, position of a column in the table.
• COLUMN_DEFAULT: Default value for a column in the table.
• IS_NULLABLE: Either YES or NO, describing whether the column allows for NULL values.
• DATA_TYPE: Shows only the data type keyword, not the entire field definition, for the
column.
CHAPTER 21 ■ MYSQL DATA DICTIONARY 679
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 679
• CHARACTER_MAXIMUM_LENGTH: Shows the maximum number of characters that the field
may contain.
• CHARACTER_OCTET_LENGTH: Shows the maximum length of the field in octets.
• NUMERIC_PRECISION: Shows the precision of numeric fields, or NULL if a non-numeric
field type.
• NUMERIC_SCALE: Shows the scale of numeric fields, or NULL if a non-numeric field type.
• CHARACTER_SET_NAME: Shows the character field character set, or NULL if a noncharacter
field type. See the section “INFORMATION_SCHEMA.CHARACTER_SETS.”
• COLLATION_NAME: Shows the character field collation set, or NULL if a noncharacter field

type. See the section “INFORMATION_SCHEMA.COLLATIONS.”
• COLUMN_TYPE: Shows the full field definition for the column.
• COLUMN_KEY: Shows any of PRI, UNI, MUL, or blank. PRI appears when the column is part
of a PRIMARY KEY. UNI appears when the column is part of a UNIQUE INDEX. MUL appears
when the column is part of an index that allows for duplicates. Blank appears for all
other columns.
• EXTRA: Shows any extra information about the column that MySQL stores; for instance,
the AUTO_INCREMENT keyword.
• PRIVILEGES: Shows a list of privileges available to the current user for this column.
• COLUMN_COMMENT: Shows the comment used during table creation.
■Note The SHOW FULL COLUMNS command is the closest equivalent to a SELECT * FROM INFORMATION_
SCHEMA.COLUMNS WHERE TABLE_NAME = 'table_name'.
The COLUMNS view has a wealth of information that doesn’t appear in the SHOW FULL ➥
COLUMNS output. The most useful part of the view output is that you get a normalized output for
numeric precision and scale, the data type, and the ordinal position of the column within the
table. This means you can avoid scripts that must parse out the non-normalized SHOW COLUMNS
output. You’ll see an example of this usage later in the chapter.
INFORMATION_SCHEMA.KEY_COLUMN_USAGE
The INFORMATION_SCHEMA.KEY_COLUMN_USAGE view details information about the columns used
in a table’s indexes or constraints. Listing 21-5 shows an output from DESCRIBE and a simple
SELECT from the view.
CHAPTER 21 ■ MYSQL DATA DICTIONARY680
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 680
Listing 21-5. INFORMATION_SCHEMA.KEY_COLUMN_USAGE
mysql> DESCRIBE INFORMATION_SCHEMA.KEY_COLUMN_USAGE;
+ + + + + + +
| Field | Type | Null | Key | Default | Extra |
+ + + + + + +
| CONSTRAINT_CATALOG | varchar(4096) | YES | | NULL | |
| CONSTRAINT_SCHEMA | varchar(64) | NO | | | |

| CONSTRAINT_NAME | varchar(64) | NO | | | |
| TABLE_CATALOG | varchar(4096) | YES | | NULL | |
| TABLE_SCHEMA | varchar(64) | NO | | | |
| TABLE_NAME | varchar(64) | NO | | | |
| COLUMN_NAME | varchar(64) | NO | | | |
| ORDINAL_POSITION | bigint(10) | NO | | 0 | |
| POSITION_IN_UNIQUE_CONSTRAINT | bigint(10) | YES | | NULL | |
+ + + + + + +
9 rows in set (0.00 sec)
mysql> SELECT * FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE
-> WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 'http_auth' \G
*************************** 1. row ***************************
CONSTRAINT_CATALOG: NULL
CONSTRAINT_SCHEMA: test
CONSTRAINT_NAME: PRIMARY
TABLE_CATALOG: NULL
TABLE_SCHEMA: test
TABLE_NAME: http_auth
COLUMN_NAME: username
ORDINAL_POSITION: 1
POSITION_IN_UNIQUE_CONSTRAINT: NULL
1 row in set (0.00 sec)
The fields contained in INFORMATION_SCHEMA.KEY_COLUMN_USAGE are as follows:
• CONSTRAINT_CATALOG: Always NULL.
• CONSTRAINT_SCHEMA: Name of the database containing the constraint.
• CONSTRAINT_NAME: Name of the constraint.
• TABLE_CATALOG: Always NULL.
• TABLE_SCHEMA: Name of the database containing the table in which the constraint can
be found. Is always the same value as CONSTRAINT_SCHEMA.
• TABLE_NAME: Name of the table on which the constraint or index operates.

| NULLABLE | varchar(3) | NO | | | |
| INDEX_TYPE | varchar(16) | NO | | | |
| COMMENT | varchar(16) | YES | | NULL | |
+ + + + + + +
15 rows in set (0.00 sec)
mysql> SELECT * FROM INFORMATION_SCHEMA.STATISTICS
-> WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 'http_auth' \G
*************************** 1. row ***************************
TABLE_CATALOG: NULL
TABLE_SCHEMA: test
TABLE_NAME: http_auth
NON_UNIQUE: 0
INDEX_SCHEMA: test
CHAPTER 21 ■ MYSQL DATA DICTIONARY682
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 682
INDEX_NAME: PRIMARY
SEQ_IN_INDEX: 1
COLUMN_NAME: username
COLLATION: A
CARDINALITY: 90000
SUB_PART: NULL
PACKED: NULL
NULLABLE:
INDEX_TYPE: BTREE
COMMENT:
1 row in set (0.00 sec)
The fields contained in INFORMATION_SCHEMA.STATISTICS are as follows:
• TABLE_CATALOG: Always NULL.
• TABLE_SCHEMA: Name of the database in which the table resides.
• TABLE_NAME: Name of the table on which the index operates.

• NON_UNIQUE: Either 0 or 1. Indicates whether the index can contain duplicate values.
Note that NON_UNIQUE returns a numeric Boolean representation, as opposed to YES
or NO.
• INDEX_SCHEMA: Name of the database in which the index is housed. It’s always the same
as TABLE_SCHEMA.
• INDEX_NAME: Name of the index within the schema.
• SEQ_IN_INDEX: Shows the position of this column within the index key, starting at
position 1.
• COLUMN_NAME: Name of the column in the index key.
• COLLATION: The column’s collation. Will either be A for an ascending index order, or NULL
for descending.
• CARDINALITY: The number of unique values contained in this column for this index key.
• SUB_PART: If a prefix on a character field was used in the creation of the index, SUB_PART
will show the number of characters that the index column uses; otherwise NULL.
• PACKED: Either 0, 1, or DEFAULT depending on whether the index is packed. See Chapter 5
for more information about MyISAM key packing.
• NULLABLE: Either YES or NO, indicating whether the column can contain NULL values.
• INDEX_TYPE: Any of BTREE, RTREE, HASH, or FULLTEXT.
• COMMENT: Any comment used during creation of the index; otherwise blank.
The STATISTICS view has a wealth of information about the columns used in your indexes.
We’ll be using this table in the following examples to get a feel for the selectivity of your
indexes, so stay tuned.
CHAPTER 21 ■ MYSQL DATA DICTIONARY 683
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 683
■Note The SHOW INDEX command most closely resembles the output from a SELECT * FROM ➥
INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 'table_name';.
INFORMATION_SCHEMA.ROUTINES
The INFORMATION_SCHEMA.ROUTINES view details information about the stored procedures and
user-defined functions created on your system. Listing 21-7 shows the output of DESCRIBE
and a simple SELECT on the view.

ROUTINE_CATALOG: NULL
ROUTINE_SCHEMA: test
ROUTINE_NAME: test_proc1
ROUTINE_TYPE: PROCEDURE
CHAPTER 21 ■ MYSQL DATA DICTIONARY684
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 684
DTD_IDENTIFIER: NULL
ROUTINE_BODY: SQL
ROUTINE_DEFINITION: BEGIN
SELECT COUNT(*) INTO param1 FROM http_auth;
END
EXTERNAL_NAME: NULL
EXTERNAL_LANGUAGE: NULL
PARAMETER_STYLE: SQL
IS_DETERMINISTIC: NO
SQL_DATA_ACCESS: CONTAINS SQL
SQL_PATH: NULL
SECURITY_TYPE: DEFINER
CREATED: 2005-04-10 13:21:58
LAST_ALTERED: 2005-04-10 13:21:58
SQL_MODE:
ROUTINE_COMMENT:
DEFINER: root@localhost
1 row in set (0.00 sec)
The listing shows a simple test procedure we’ve created in the test schema for illustration
purposes. If you’re unfamiliar with stored procedures, please refer to Chapter 9.
The fields contained in INFORMATION_SCHEMA.ROUTINES are as follows:
• SPECIFIC_NAME: The name of the stored procedure or function.
• ROUTINE_CATALOG: Always NULL.
• ROUTINE_SCHEMA: The name of the database to which the procedure is tied.

• ROUTINE_NAME: Same as SPECIFIC_NAME.
• ROUTINE_TYPE: Either PROCEDURE or FUNCTION.
• DTD_IDENTIFIER: For functions, returns the complete data type definition of the func-
tion, otherwise NULL for procedures.
• ROUTINE_BODY: Shows the language in which the procedure is written. Currently, only the
value SQL appears, but in future versions of MySQL, other extension languages may be
used to write procedures.
• ROUTINE_DEFINITION: For procedures, shows either the whole procedure definition, or
for long procedures, a truncated part of the definition.
• EXTERNAL_NAME: Always NULL, because all stored procedures in MySQL are kept internal
to the database.
• EXTERNAL_LANGUAGE: Again, always NULL.
• PARAMETER_STYLE: Currently, only the value SQL appears for this column.
• IS_DETERMINISTIC: Either YES or NO. Shows whether the stored procedure or function
will return the same value for the same passed input parameters.
• SQL_DATA_ACCESS: Any of NO SQL, CONTAINS SQL, READS SQL DATA, or MODIFIES SQL DATA.
See Chapter 9 for an explanation of these various values.
CHAPTER 21 ■ MYSQL DATA DICTIONARY 685
505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 685

Pro MySQL experts voice in open source phần 10 ppt

Tài liệu liên quan

Tài liệu bạn tìm kiếm đã sẵn sàng tải về