MySQL 5.7 Important Features
InnoDB Read-Only Scalability
Improving the performance for Read-Only and Read-Mostly workloads. Significantly improved how InnoDB handles RO trans-actions
Removed server layer contentions related to Meta Data Locking (MDL) and removed the use of “thread locks” (thd_locks) for InnoDB
In MySQL 5.7.2, there is another optimization where all transactions are treated as a read-only transactions by default, and a transaction is only
assigned an ID and a rollback segment when the transaction attempts to do its first update. This optimization of treating all transactions as
read-only by default has the additional benefit that users do not need to use special syntax or change their applications to take advantage of it.
InnoDB Read-Write Scalability.
Improved the performance of Read-Write (RW) workloads. We have removed the “index lock contention” in InnoDB. The index lock that was
used to protect the entire index tree structure is now replaced by more fine grained “block locks” in the tree.
InnoDB has two "modes" when updating the Btrees. An optimistic mode and a pessimistic mode. They roughly correspond to in-place changes
and tree modification changes. If InnoDB thinks that an insert/delete will result in a tree modification change it will lock the index in X mode.
This blocks readers too and limits concurrency. The fix was to introduce a new lock mode SX. This reduces the need to lock the entire Btree
during tree modification changes.
InnoDB Faster & Parallel Flushing
InnoDB has had some sub-optimal code around traversing the dirty page and LRU list flushing. The problem was that when we release the
buffer pool and associated mutexes during the IO phase we can no longer trust the iterator that is used to scan the aforementioned lists. So, we
restart the scan from the start. The fix was to track whether the iterator was invalidated while the covering mutexes where released. If the
iterator was not invalidated then we can carry on from where we left off. If on the other hand we detect that it was invalidated we go back to
the start and do it the old way. The iterator invalidation should be very rare.
Reducing the number of pages scanned when doing flush list batches, speeding up page flushing
Recently our benchmarks showed that we are scanning excessive number of pages when
doing flush list batches. We fixed it by introducing the concept of Hazard Pointer
which reduced the time complexity of scan from O(n*n) to O(n). This WL builds on
that to extend the same concept to other scans within buffer pool. There are
significant other changes which are made as part of reduced scanning logic.
The time complexity of a scan is reduced from O(n*n) to O(n). We have also implemented parallel flushing by having multiple page_cleaner
Speeding up Connection Handling
In 5.7 we have offloaded thread initialization and network initialization to a worker thread and more than doubled MySQL’s ability to do high
frequency connect/disconnect cycles, from 26K to 56K connect/disconnect cycles per second
Bulk Data Load Improvements
Bulk Load for Create Index – Faster index creation
This method of index creation is also known as a “sorted index build”. This enhancement, which improves the efficiency of index creation, also
applies to full-text indexes. A new global configuration option, innodb_fill_factor, defines the percentage of space on each page that is filled
with data during a sorted index build, with the remaining space reserved for future index growth. For more information, see Section 14.13.18,
“Bulk Load for CREATE INDEX”.
Bulk INSERT operations can be sped up by creating the secondary indexes afterwards. In this way, the records will be merge sorted and then
inserted into the InnoDB index B-trees in order, using sequentially allocated pages. This will create a more optimal layout especially for indexes
whose columns are updated rarely
Resize the InnoDB Buffer Pool Online
Change “ innodb_buffer_pool_size“ dynamically.
Automatic Truncation of UNOD Logs
Need separate UNDO tablespaces have been configured.
InnoDB Online Alter Table
Onine rename index and enlarge varchar column size
Online Rename Index This work by Marko Mäkelä (WL#6752) and Dmitry Lenev (WL#6555) makes it possible to rename an index as an online operation. Example:
mysql> ALTER TABLE t RENAME INDEX i1 TO i2;
Enlarge VARCHAR column size online (WL#6554) This work by Marko Mäkelä makes it possible to enlarge varchar column sizes as an online operation. This is true as
long as the number of bytes required by the VARCHAR column type (VARCHAR/LONGVARCHAR) remains the same, i.e. from 0 to 255 or from 256 to higher. Example:
mysql> ALTER TABLE t1 ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(255);
Setting Replication Filters Without Server Restart
Dynamically change Filter behaviors without restart server
CHANGE MASTER Without Stopping the SQL Thread
In order to add/alter an option using the CANGE MASTER TO command, it was previously necessary to issue a STOP SLAVE command before
the CHANGE MASTER TO command. This work relaxes that constraint.
Improved “IN queries” With Row Value Expressions to Be Executed Using Range Scans
As of 5.7.3 this hole in the net is stitched up. The range optimizer gladly opens the door for queries with IN predicates as long as
The predicate is only IN, not NOT IN.
The row on the predicate’s left-hand side is only indexed column references, in the same index.
The rows contain only constants or come from a previously read table in nested-loops join.
Note that ‘constants’ is a pretty broad category. It consists of pre-evaluated expressions, even some sub-queries, SQL variables and similar
Improving performance when using in predicates
UNION ALL” No Longer Creates a Temporary Table
In 5.7 the optimizer avoids creating a temporary table for the result of UNION ALL queries when there is no need for it, i.e., when there is no
top-level ORDER BY clause
EXPLAIN for Running Queries
This feature is useful if you are running a statement in one session that is taking a long time to complete; using EXPLAIN FOR CONNECTION in
another session may yield useful information about the cause of the delay and thus help you optimize your schema and statements.
Make Use of Condition Filtering in the Optimizer
Improved ONLY_FULL_GROUP_BY SQL Mode
ONLY_FULL_GROUP_BY SQL mode was enabled by default in 5.75+
In MySQL, one can write GROUP BY queries that reference non-aggregated columns in the SELECT list that are not included in the GROUP BY
clause, even if these columns are not functionally dependent upon the GROUP BY clause. This behaviour conforms to none of the SQL standard's
versions. It is possible to avoid this behaviour by including ONLY_FULL_GROUP_BY in the sql_mode server setting, but it might make more sense
to take advantage of the ability to write only partial GROUP BY clauses.
In a nutshell:
It is completely safe to write partial GROUP BY clauses as long as all non-aggregated columns in the SELECT list are functionally dependent upon
the GROUP BY clause.
A partial GROUP BY list can result in better performance, because it keeps the server from evaluating the entire GROUP BY list.
If one does not want to write partial GROUP BY clauses, consider using MIN or MAX to 'aggregate' the functionally dependent columns in the
SELECT list rather than moving the functionally dependent columns to the GROUP BY clause.
Copying File-Per-Table Tablespaces to Another Server
Prior to MySQL 5.7.4, only non-partitioned InnoDB tables are supported. As of MySQL 5.7.4, partitioned InnoDB tables and individual InnoDB
table partitions and subpartitions are also supported.
InnoDB Buffer Pool Dump and Load Enhancements
This work improves both the dump and load scenarios. It is now possible to dump only the hottest N% of the pages from each buffer pool. The load
operation is also made less disruptive to user activity because the load now happens in the background while continuing to serve clients
MySQL 5.7.4 introduces the ability to set server side execution time limits, specified in milliseconds, for top level read-only SELECT statements.
This feature is introduced as part of WL#6936. It is based on a contribution submitted by Davi Arnaut with Bug#68252. Thank you, Davi!
The statement timeouts work by interrupting the execution of the statement when it takes longer than a specified number of milliseconds to
complete. After the specified number of milliseconds has passed, the server aborts the individual query without affecting the larger transaction
or connection contexts. The following error is then reported to the client when the query is aborted:
1907: Query execution was interrupted, max_statement_time exceeded.
To be clear, the execution time limit specified is really a “soft hint”, because the query interruption may not happen precisely at the specified
execution time limit. There can be a minor delay between the timer expiration and the actual query interruption.
A time limit for any SELECT statement run against a MySQL instance can be set by specifying a timeout value in milliseconds for the GLOBAL
system variable max_statement_time.
Multiple User Level Locks
The difference in lock acquisition behavior as of MySQL 5.7.5 can be seen by the following example. Suppose that you execute these
In MySQL 5.7.5 or later, the second GET_LOCK() acquires a second lock and both RELEASE_LOCK() calls return 1 (success). Before MySQL 5.7.5,
the second GET_LOCK() releases the first lock ('lock1') and the secondRELEASE_LOCK() returns NULL (failure) because there is no 'lock1' to
Waiting for More Transactions to Enter Binlog Group Commit (BGC) Queues
Solve the lag problem in MySQL slave database. We could read Booking’s article for cascade M-S architecture.
binlog-group-commit-sync-delay, binlog-group-commit-sync-no-delay-count were used to control BGC.
Make the Master Wait for More than One Slave to Acknowledge Back
Externalize Transactions Only after ACK is Received
Semi-Sync — Separate ACKs Collector
Multi-Threaded Slaves (MTS)
Intra-Schema Parallel Slave Execution
Ordered Commits (Sequential Consistency)
Ensure that the commits by slave applier threads running in parallel will be done in the same order as they were on the master.
Support Slave Transaction Retries in Multi-Threaded Slave Mode
Transaction retry feature works for both types of mutli-threaded slave(database based and logical clock based). It also works fine when you
force slave to commit transactions in same order as master by setting system variable “slave_preserve_commit_order” to ON.
By default, transaction retry is on for all types of slave. Multi-threaded slave will not break if it just encounters some temporary errors
TRUNCATE TABLE Statement Becomes Atomic
This work makes the internal InnoDB TRUNCATE TABLE statement atomic by reinitializing the original table-space header with the same space
id and then physically truncating its.ibd file during the truncation of a single table tablespace.
InnoDB Create Tablespace in 5.7
CREATE TABLESPACE `TBS_DADOS_COMPRESS` ADD DATAFILE 'TDS_DC_DATAFILE1.ibd' [FILE_BLOCK_SIZE=4];
CREATE TABLESPACE `TBS_DADOS` ADD DATAFILE 'TDS_D_DATAFILE1.ibd' [FILE_BLOCK_SIZE=8];
CREATE TABLE ITEM_VENDA TABLESPACE=`TBS_DADOS_COMPRESS`;
ALTER TABLE tbl_name TABLESPACE=`TBS_DADOS`
DROP TABLESPACE `TBS_DADOS_COMPRESS`;
InnoDB Native Partitioning
Less handles less use of memory. Easy to access partition tables
InnoDB Temporary Table Performance
No redo logging
Separate tablespace for all uncompressed temporary tables
Temporary tables don't require recovery therefore there is no point in saving their definitions in the persistent data dictionary. By putting the all
the temporary tables in a special tablespace that is not redo logged we can reduce a lot of the unnecessary overhead. We do UNDO log the
changes to temporary tables, this is required for rollback to savepoint. However, the UNDO logs for temporary tables are not redo logged and
the UNDO logs for temporary tables also reside in the special temporary tablespace.
Temp tables are only visible within the connection/session in which they were created, and they are bound by the lifetime of the server. We
optimized DML for Temp Tables (WL#6470) by removing unnecessary UNDO and REDO logging, change buffering, and locking. We added an
additional type of UNDO log (WL#6915), one that is not REDO logged and resides in a new separate temp tablespace.
Nearly MariaDB. MySQL 5.7 starting to support Multi-Source replication.
There are two kinds of Generated Columns: virtual (default) and stored. Virtual means that the column will be calculated on the fly when a
record is read from a table. Stored means that the column will be calculated when a new record is written in the table, and after that it will be
treated as a regular field. Both types can have NOT NULL restrictions, but only a stored Generated Column can be be a part of an index.
SYS schema In MySQL
New in MySQL 5.7.7, the MySQL sys schema (originally the ps_helper project) is now included by default within the MySQL server
Improved alter user syntax support in 5.7
Change Alter user syntax and add more useful commands.
SSL/TLS IN MYSQL 5.7
Security is receiving more attention and MySQL 5.7 aims to be the most secure MySQL Server release ever.
Secondary Indexes on XML BLOBs
We can create secondary index on this Column with generated column feature
Emulating roles with expanded proxy user support in 5.7.7
Explain how to use proxy user in MySQL