0% found this document useful (0 votes)
59 views4 pages

Mysql Storage Engines and Data Types

This document discusses MySQL storage engines and data types. It describes the key storage engines like InnoDB and MyISAM, their advantages and disadvantages. It also covers MySQL data types and how to create, modify and manage databases and tables using SQL commands.

Uploaded by

Ahmadullah Ahmad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
59 views4 pages

Mysql Storage Engines and Data Types

This document discusses MySQL storage engines and data types. It describes the key storage engines like InnoDB and MyISAM, their advantages and disadvantages. It also covers MySQL data types and how to create, modify and manage databases and tables using SQL commands.

Uploaded by

Ahmadullah Ahmad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

CHAPTER 25: MySQL Storage Engines and Data Types

1. The purpose, advantages, disadvantages, and relevant configuration parameters of MySQL’s key storage
engines, namely ARCHIVE, BLACKHOLE, CSV, EXAMPLE, FEDERATED, InnoDB, MEMORY
(formerly HEAP), MERGE, and MyISAM.
2. The purpose and range of MySQL’s supported data types. To facilitate later reference, these data types
are broken into three categories: date and time, numeric, and textual.
3. MySQL’s table attributes, which serve to further modify the behavior of a data column.
4. The MySQL commands used to create, modify, navigate, review, and alter both databases and tables.
5. A relational database table is a data structure used to store and organize information.
6. SHOW is used for learning quite a bit about the server’s configuration, including user privileges,
supported table engines, executing processes, and more.

1. CHARACTER_SETS: Stores information about the available character sets.

2. COLLATIONS: Stores information about character set collations.


3. COLLATION_CHARACTER_SET_APPLICABILITY: A subset of the
i. INFORMATION_SCHEMA.COLLATIONS table, it matches character sets to
ii. each respective collation.
4. COLUMNS: Stores information about table columns, such as a column’s name,
data type, and whether it’s nullable.
5. COLUMN_PRIVILEGES: Stores information about column privileges. Keep in
mind that this information is actually retrieved from the
mysql.columns_priv table; however, retrieving it from this table offers the
opportunity for additional uniformity when querying
i. database properties.
ii. ENGINES: Stores information about available storage engines.
6. EVENTS: Stores information about scheduled events. Scheduled events
are out of the scope of this book; consult the MySQL
i. documentation for more information.
7. FILES: Stores information about NDB disk data tables. NDB is a
i. storage engine that is out of the scope of this book; consult the
MySQL documentation for more information.

8. GLOBAL_STATUS: Stores information about server status variables.

9. GLOBAL_VARIABLES: Stores information about server settings.

10. KEY_COLUMN_USAGE: Stores information about key column constraints.

11. PARTITIONS: Stores information about table partitions.


12. PLUGINS: Stores information about plug-ins, a feature new to MySQL
5.1 and out of the scope of this book. Consult the MySQL
i. documentation for more information.

13. PROCESSLIST: Stores information about currently running threads.


14. PROFILING: Stores information about query profiles. You can also find this
information by executing the SHOW PROFILE and SHOW PROFILES
i. commands.

15. REFERENTIAL_CONSTRAINTS: Stores information about foreign keys.


16. ROUTINES: Stores information about stored procedures and functions.
17. SCHEMATA: Stores information about the databases located on the
server, such as the database name and default character set.
18. SCHEMA_PRIVILEGES: Stores information about database privileges. Keep
in mind that this information is actually retrieved from the mysql.db table;
however, retrieving it from this table offers the opportunity for additional
uniformity when querying database
i. properties.

19. SESSION_STATUS: Stores information about the current session.


20. SESSION_VARIABLES: Stores information about the current session’s
configuration.
a. STATISTICS: Stores information about each table index, such as the
i. column name, whether it’s nullable, and whether each row
must be unique.
b. TABLES: Stores information about each table, such as the name,
engine, creation time, and average row length.
c. TABLE_CONSTRAINTS: Stores information about table constraints, such as
whether it includes UNIQUE and PRIMARY KEY columns.
d. TABLE_PRIVILEGES: Stores information about table privileges. Keep in
mind that this information is actually retrieved from the mysql.
tables_priv table; however, retrieving it from this table offers the
i. opportunity for additional uniformity when querying
database properties.
e. TRIGGERS: Stores information about each trigger, such as whether it
fires according to an insertion, deletion, or modification. Note that
this table wasn’t added to the INFORMATION_SCHEMA until version
i. 5.0.10. USER_PRIVILEGES: Stores information about global privileges. Keep
in mind that this information is actually retrieved from the mysql.user
ii. table; however, retrieving it from this table offers the
opportunity for additional uniformity when querying
database properties.
f. VIEWS: Stores information about each view, such as its definition and
whether it’s updatable.

Creating a Table
A table is created using the CREATE TABLE statement.
CREATE TABLE employees (
id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT,
firstname VARCHAR(25) NOT NULL,
lastname VARCHAR(25) NOT NULL,
email VARCHAR(45) NOT NULL, phone
VARCHAR(10) NOT NULL, PRIMARY
KEY(id));
if you want to create the employees table only if it doesn’t already exist, do the
following:

CREATE TABLE IF NOT EXISTS employees (


id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT,
firstname VARCHAR(25) NOT NULL,
lastname VARCHAR(25) NOT NULL,
email VARCHAR(45) NOT NULL, phone
VARCHAR(10) NOT NULL, PRIMARY
KEY(id));

Copying a Table
It’s a trivial task to create a new table based on an existing one. The following query
produces an exact copy of the employees table, naming it employees2:
CREATE TABLE employees2 SELECT * FROM employees;
An identical table, employees2, will be added to the database. Sometimes you need to create a
table based on just a few columns found in a preexisting table. You can do so by simply specifying
the columns within the CREATE SELECT statement:
CREATE TABLE employees3 SELECT firstname, lastname FROM employees;

Altering a Table Structure


You’ll find yourself often revising and improving your table structures, particularly in the
early stages of development. However, you don’t have to go through the hassle of
deleting and re-creating the table every time you’d like to make a change. Rather, you can
alter the table’s structure with the ALTER statement. With this statement, you can delete,
modify, and add columns as you deem necessary.
ALTER TABLE employees ADD COLUMN birthdate DATE;
ALTER TABLE employees ADD COLUMN birthdate DATE AFTER lastname;
Whoops, you forgot the NOT NULL clause! You can modify the new column:
ALTER TABLE employees CHANGE birthdate birthdate DATE NOT NULL;
ALTER TABLE employees DROP birthdate;

InnoDB
InnoDB is a robust transactional storage engine released under the GNU General Public
License (GPL) that has been under active development for over a decade. InnoDB offers
users a powerful solution for working with very large data stores.
InnoDB tables are ideal for the following scenarios, among others:
• Update-intensive tables: The InnoDB storage engine is particularly
adept at handling multiple simultaneous update requests.

• Transactions: The InnoDB storage engine is the only standard


MySQL storage engine that supports transactions, a requisite feature
for managing sensitive data such as financial or user registration
information.

• Automated crash recovery: Unlike other storage engines, InnoDB


tables are capable of automatically recovering from a crash. Although
MyISAM tables can also be repaired after a crash, the process can take
significantly longer. A crash safe version of MyISAM called Aria is also
available.

MyISAM
MyISAM used to be MySQL’s default storage engine. It resolved a number of deficiencies
suffered by its predecessor (ISAM). For starters, MyISAM tables are operating system
independent, meaning that you can easily port them from a Windows server to a Linux server.
In addition, MyISAM tables are typically capable of storing more data, but at a cost of less
storage space than their older counterpart. MyISAM tables also have the convenience of a
number of data integrity and compression tools at their disposal, all of which are bundled
with MySQL.
MyISAM tables cannot handle transactions and used to be preferred over InnoDB
when performance was an issue. Over time, the performance of InnoDB has increased
and is no longer an issue in most cases. The MyISAM storage engine was particularly
adept when applied to the following scenarios:
• Select-intensive tables: The MyISAM storage engine is quite fast at
sifting through large amounts of data, even in a high-traffic
environment.

• Append-intensive tables: MyISAM’s concurrent insert feature allows for


data to be selected and inserted simultaneously. For example, the
MyISAM storage engine would be a great candidate for managing
mail or web server log data.

You might also like