Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MySQL 5.7 milestone

MySQL 5.7+ new features !

  • Login to see the comments

MySQL 5.7 milestone

  1. 1. 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. Reference:
  2. 2. 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. Reference:
  3. 3. 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 threads Reference:
  4. 4. 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 Reference: 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”.
  5. 5. 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. Reference: Automatic Truncation of UNOD Logs Need separate UNDO tablespaces have been configured. Reference:
  6. 6. 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 Reference:
  7. 7. 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. Reference: 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 beings
  8. 8. Improving performance when using in predicates Reference: 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 Reference:
  9. 9. 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. JSON EXPLAIN Make Use of Condition Filtering in the Optimizer Reference:
  10. 10. 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. Reference:
  11. 11. 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. Reference: 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 Reference:
  12. 12. Statement Timeouts 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.
  13. 13. Reference: 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 statements: SELECT GET_LOCK('lock1',10); SELECT GET_LOCK('lock2',10); SELECT RELEASE_LOCK('lock2'); SELECT RELEASE_LOCK('lock1'); 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 release.
  14. 14. 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. Reference: Semi-Sync Replication Make the Master Wait for More than One Slave to Acknowledge Back Externalize Transactions Only after ACK is Received Semi-Sync — Separate ACKs Collector Reference:
  15. 15. Multi-Threaded Slaves (MTS) Intra-Schema Parallel Slave Execution Reference: 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.
  16. 16. 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 mentioned above. 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. Reference:
  18. 18. InnoDB Temporary Table Performance Temporary Tables Faster create/drop 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.
  19. 19. Multi-Source Replication Nearly MariaDB. MySQL 5.7 starting to support Multi-Source replication. Generated Columns 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. Reference:
  20. 20. 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 Reference: Improved alter user syntax support in 5.7 Change Alter user syntax and add more useful commands. Reference:
  21. 21. 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. Reference: Secondary Indexes on XML BLOBs We can create secondary index on this Column with generated column feature Reference:
  22. 22. Emulating roles with expanded proxy user support in 5.7.7 Explain how to use proxy user in MySQL Reference: