The MySQL Development team is happy to announce our 8.0.1 development milestone release (DMR), now available for download at dev.mysql.com. (8.0.1 adds features to 8.0.0). The source code is available at GitHub. You can find the full list of changes and bug fixes in the 8.0.1 Release Notes. Here are the highlights. Enjoy!
Character Sets
We are continuing our work on UTF8MB4 support for MySQL 8.0. In 8.0.1 we make UTF8MB4 the default character set, we add case and accent sensitive collations, and we add our first Japanese collation for UTF8MB4.
Switch to new default character set and change mtr test cases (WL#7554) — This work by Xing Zhang, Bernt Johnsen, and Tor Didriksen changes the default value of character_set_server from latin1 to utf8mb4 and the default collation for utf8mb4 to utf8mb4_0900_ai_ci. This work includes changes to MTR test cases as well as many performance improvements related to utf8mb4 character comparison done as bug fixes by Steinar Gunderson.
Add case and accent sensitive collations for utf8mb4 (WL#9109) — This work by Xing Zhang adds case and accent sensitive collations for utf8mb4. DUCET (Default Unicode Collation Entry Table) defines 3 levels of collation weight. The primary level is used to compare the base character, the secondary level is used to compare accent if the base letters are equal, and the tertiary level is used to compare case if the base letter and its accent are equal. Case and accent sensitive collations use all 3 levels’ weight.
Add Japanese collation to utf8mb4 (WL#9751) — This work by Xing Zhang implements Japanese collation for utf8mb4 on the base of utf8mb4 collations built on latest Unicode 9.0. Until now we have had Japanese collations for SJIS and UJIS character sets, but not for UTF8MB4. This work gives the correct sorting order for Japanese.
Make Unicode 9.0.0 and newer collations NO PAD (WL#10354) — This work by Steinar Gunderson changes all new collations, from Unicode 9.0.0 forward, to be NO PAD instead of PAD STRING, ie., treat spaces at the end of a string like any other character. This is done to improve consistency and performance. Older collations are left in place.
GIS
We are continuing our work towards full geography support in MySQL 8.0, guided by OpenGIS and ISO standards. The biggest change to GIS in 8.0.1 is that for the first time we do real geographic calculations in MySQL (in ST_Distance()).
Ellipsoidal ST_Distance for point and multipoint (WL#9347) — This work by Norvald Ryeng extends ST_Distance() to detect that its parameters are in a geographic (ellipsoidal) SRS and to compute the distance on the ellipsoid. Before this work, MySQL’s ST_Distance()only supported computations in Cartesian spatial reference systems (SRSs).
Step towards geographic R-trees (WL#9439) — This work by Darshan M N moves the geometry code related to geometry parsing, computing bounding boxes and operations on them, from the InnoDB layer to the Server layer so that geographic R-trees can be supported more easily in the future.
Require WKB input in WKB parsing functions (WL#10166) — This work by Jens Even B. Blomsøy modifies the behavior of ST_GeomFromWKB(), ST_GeometryFromWKB(), and similar functions by requiring the WKB parameter to be WKB. It removes the support for using geometries as parameters to these functions.
Axis order in ST_AsBinary/ST_AsWKB (WL#9432) — This work by Hans Melby modifies the ST_AsBinary() and ST_AsWKB() functions to return geographic (latitude and longitude) coordinates in the order specified in the spatial reference system. An optional options argument and an option argument value to override the default and specify a particular axis order are also added.
Axis order in ST_AsText/ST_AsWKT (WL#9433) — This work by Hans Melby modifies the ST_AsText() and ST_AsWKT() functions to return coordinates in the order specified in the spatial reference system. An optional options argument and an option argument value to override the default and specify a particular axis order are also added.
Axis order in WKT parsing functions (WL#9434) — This work by Jens Even B. Blomsøy modifies ST_GeomFromText(), ST_GeometryFromText(), and similar functions to accept coordinates in the order specified in the spatial reference system. An optional argument to override the default axis order has also been added.
Axis order in WKB parsing functions (WL#9435) — This work by Jens Even B. Blomsøy modifies ST_GeomFromWKB(), ST_GeometryFromWKB(), and similar functions to accept coordinates in the order specified in the spatial reference system. An optional options argument and an option argument value to override the default and specify a particular axis order are also added.
ST_SwapXY (WL#9436) — This work by Jens Even B. Blomsøy adds a function ST_SwapXY()that swaps all coordinate pairs in a geometry. Data may be in latitude-longitude or longitude-latitude format. MySQL will interpret stored geometries as if they are in longitude-latitude format, i.e., the first coordinate is longitude, the second is latitude. The motivation for this function is that users may have existing data that assumes the wrong axis order for geographic data.
INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNS (WL#8582) — This work by Norvald Ryeng adds the INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNS view as specified in SQL/MM Part 3, Sect. 19.2. The view is backed by INFORMATION_SCHEMA.COLUMNS. The SRS_NAME and SRS_IDcolumns are always NULL until the SRID type modifier for geometric types has been implemented.
INFORMATION_SCHEMA.ST_SPATIAL_REFERENCE_SYSTEMS (WL#9348) — This work by Norvald Ryeng implements the INFORMATION_SCHEMA.ST_SPATIAL_REFERENCE_SYSTEMSview as defined in SQL/MM Part 3 Sect. 19.3. The view is not updatable. Spatial reference system (SRS) definitions were implemented by WL#8579 and are stored in the data dictionary table mysql.st_spatial_reference_systems. This table is not meant to be used by users/DBAs and will be hidden by future WLs. In order to inspect the SRS definitions, to find out which SRSs are supported and which SRID refers to which SRS, the users need an INFORMATION_SCHEMA view to this information.
Cost Model
We are continuing our work on improving the MySQL cost model . The biggest change to the cost model in 8.0.1 is that for the first time we choose query plans based on knowledge about whether data resides in-memory or on-disk. This happens automatically, as seen from the end user there is no configuration involved. Historically, the MySQL cost model has assumed data to reside on spinning disks.
IO aware defaults for optimizer cost constants (WL#8737) — This work by Olav Sandstå changes the cost constant default values in optimizer cost tables (server_cost and engine_cost). The cost constants associated with looking up data in-memory and on-disk are now different, thus, the optimizer will choose more optimal access methods for the two cases, based on knowledge of the location of data.
Add defaults column to optimizer cost tables (WL#10128) — This work by Øystein Grøvlen adds a generated column that will show the default values for the constants defined in the two tables, server_cost and engine_cost, added to the mysql schema in 5.7. These tables can be used to tune the cost constants that are used for the optimizer cost model. This work exposes the default value for these cost constants to the user.
Introduce new sys variable to include estimates for delete marked records (WL#9513) — This work by Aditya A introduces a system variable innodb_stats_include_delete_markedwhich when enabled includes delete marked records in the calculation of table and index statistics. This work was done to overcome a problem with “wrong” statistics where an uncommitted transaction has deleted all rows in the table. While calculating persistent stats we were ignoring the delete marked records which led to bad query plans for other transactions operating on the table.
Histograms
We are continuing our work towards full histogram support in 8.0. With histograms, the user can create statistics on data distribution, typically for non-indexed columns, which will then be used by the optimizer in finding the optimal query plan.
Define new handler API for sampling (WL#9127) — This work by Erik Frøseth specifies a new handler API for sampling a given table. The main use case for the new API is for building histograms. Creating a histogram for a large table can be very costly. Building a histogram over a sample of the data is much more efficient, and it will still give a reasonably good histogram.
Optimizer Hints
In 5.7 we introduced a new hint syntax for optimizer hints. With the new syntax, hints can be specified directly after the SELECT | INSERT | REPLACE | UPDATE | DELETE keywords in an SQL statement, enclosed in /*+ */ style comments [1]. In 8.0.1 we add index merge and join order hints in this new style.
Index merge hints (WL#9167) — This work by Sergey Glukhov adds hints for INDEX_MERGEand NO_INDEX_MERGE. This allows the user to control index merge behavior for an individual query without changing the optimizer switch.
Join Order Hints (WL#9158) — This work by Sergey Glukhov adds hints for JOIN_FIXED_ORDER, JOIN_ORDER, JOIN_PREFIX, and JOIN_SUFFIX. This allows the user to control table order for the join execution.
We prefer the new style of optimizer hints as preferred over the old-style hints and setting of optimizer_switch values. By not being inter-mingled with SQL, the new hints can be injected in many places in a query string (possibly by an application or proxy without needing to understand or parse SQL). They also have clearer semantics in being a hint (vs directive). To explain the difference, consider the case that an index which no longer exists is hinted at with an INDEX_MERGE hint. Because the query SQL semantics are still well understood, the hint will be ignored with a warning generated. The previous generation hints would have instead resulted in an error.
The advantage of using hints over the optimizer_switch is that the granularity of hints is much more usable for applications. Because the optimizer_switch is configurable on a session or global basis it makes it difficult to maintain internal knowledge of which queries benefited from a configuration change. This means that while it is easy to disable a switch, re-enabling it after an upgrade requires very careful testing. By retaining the context of hints within a query, identifying which queries require re-testing is greatly simplified. Hint granularity may also be specified at a query block level, which is also useful for scenarios where only part of the query benefits from a change in optimizer_switch.
JSON
JSON support was introduced in 5.7. In 8.0.1 we add new JSON functions and improve performance for sorting and grouping JSON values.
Add JSON_PRETTY function (WL#9191) — This work by Knut Hatlen implements a JSON_PRETTY() function in MySQL. The JSON_PRETTY() function accepts either a JSON native data-type or string representation of JSON and returns a JSON formatted string in a human-readable way with new lines and indentation.
JSON aggregation functions (WL#7987) — This work by Catalin Besleaga adds the aggregation functions JSON_ARRAYAGG(jsoncol) to generate JSON arrays and JSON_OBJECTAGG(id, jsoncol) to generate JSON objects . This makes it possible to combine JSON documents in multiple rows into a JSON array or a JSON object. See also Catalin’s blog post here.
Varlen keys for sorting JSON values (WL#8741) — This work by Tor Didriksen gives better performance for sorting/grouping JSON values by using variable length sort keys. Preliminary benchmarks shows from 20% to 18 times improvement in sorting, depending on use case.
Common Table Expression
In 8.0.1 we deliver Common Table Expressions, a commonly requested SQL feature. See for example feature request 16244 (SQL-99 Derived table WITH clause) and 32174 (MySQL needs the hierarchy support) .
Non-recursive WITH clause (WL#883) and Recursive WITH (WL#3634) — This work by Guilhem Bichot adds [Recursive] Common Table Expressions (CTEs) in MySQL. Non-recursive CTEs can be explained as “improved derived tables” as it allow the derived table to be referenced more than once. A recursive CTE is a set of rows which is built iteratively: from an initial set of rows, a process derives new rows, which grow the set, and those new rows are fed into the process again, producing more rows, and so on, until the process produces no more rows. See also blog posts here, here, and here.
Allow multiple readers and one writer on InnoDB internal tmp table (WL#9248) — This work by Vasil Dimov implements support for multiple readers and single writer access to the same intrinsic table and still maintains the context for them separately. This work implements necessary changes inside InnoDB to support CTEs.
NOWAIT and SKIP LOCKED
In 8.0.1 we deliver NOWAIT and SKIP LOCKED, another frequently requested SQL feature. See for example feature request 49763 (Skip locked rows). We also want to say thank you to Kyle Oppenheim for his code contribution!
Implement NOWAIT and SKIP LOCKED — This work by Martin Hansson (WL#3597) and Shaohua Wang (WL#8919) implements NOWAIT and SKIP LOCKED alternatives in the SQL locking clause. Normally, when a row is locked due to an UPDATE or a SELECT ... FOR UPDATE, any other transaction will have to wait to access that locked row. In some use cases there is a need to either return immediately if a row is locked or ignore locked rows. A locking clause using NOWAIT will never wait to acquire a row lock. Instead, the query will fail with an error. A locking clause using SKIP LOCKED will never wait to acquire a row lock on the listed tables. Instead, the locked rows are skipped and not read at all.
Descending Indexes
In 8.0.1 we deliver Descending Indexes, another frequently requested SQL feature. See for example feature request 13375 (Index with Desc sort feature).
Add Descending indexes support — This work by Evgeny Potemkin (WL#1074) and Satya Bodapati (WL#7737) provides support for indexes in descending order. Values in such an index are arranged in descending order, and we scan it forward. Before 8.0.1, when a user create a descending index, we created an ascending index and scanned it backwards. One benefit is that forward index scans are faster than backward index scans. Another benefit of a real descending index is that it enables us to use indexes instead of filesort for an ORDER BY clause with mixed ASC/DESC sort key parts. See also the blog post here.
GROUPING
In 8.0.1 we deliver SQL GROUPING(). See feature requests 3156 and 46053. Thank you to Zoe Dong and Shane Adams for code contributions in feature request 46053 !
GROUPING() function (WL#1979) — This work by Chaithra Gopalareddy implements GROUPING(), SQL_FEATURE T433. The GROUPING() function distinguishes super-aggregate rows from regular grouped rows. GROUP BY extensions such as ROLLUP produce super-aggregate rows where the set of all values is represented by null. Using the GROUPING()function, you can distinguish a null representing the set of all values in a super-aggregate row from a NULL in a regular row.
With this worklog we can in future allow ROLLUP with ORDER BY (as of today ORDER BY is not allowed with ROLLUP in MySQL) and users can use GROUPING() in ORDER BY to get the sorted results with ROLLUP which is currently given by non-standard GROUP BY ASC/DESC.
Prepared Statements
In 8.0.1 we deliver a first step towards improved prepared statements. Our current focus is on proper reuse of prepared statements within a single connection. Longer term we hope to implement feature requests such as 38732 (Global Prepared Statement).
Create SQL command classes for DML statements (WL#5094) — This work by Roy Lyseng is code refactoring supporting work on prepared statements. It creates classes derived from Sql_cmd that represent all supported data manipulation (DML) statements. It gives a consistent interface to all DML statements and an interface to prepare and unprepare such statements.
X Plugin
In 5.7.12 we introduced an alternative client-server protocol called the X Protocol. We also delivered the server side implementation called the X Plugin. In 8.0.1 we add support for accounts which use sha256_password authentication over the X Protocol. In 8.0.1 we also enable the X Plugin to use prepared statements.
Mysqlx authentication of users using SHA256-auth-plugin (WL#9271) — This work by Grzegorz Szwarc implements support for accounts that use the sha256_password plugin. Authentication against sha256_password transmits a clear-text-password over a TLS encrypted connection, the server computes the hash using SHA256, and the hash is then compared to the hash stored in the user table. See also the blog post here.
Exposing PS execution to plugins (WL#8413) — This work by Catalin Besleaga refactors the Prepared Statement implementation to allow protocol plugins to use Prepared Statements. In 5.7 we introduced an API to execute server commands, like COM_QUERY, by decoupling the commands from their input. This work in 8.0.1 extends the 5.7 work by converting the COM_STMT_EXECUTE command so that prepared statements can be used via protocol plugins.
Data Dictionary
In 8.0.0 we introduced the new data dictionary. For background and additional information see blog posts here, here, and here. In 8.0.1 we deliver the next steps towards the final implementation as outlined in the 8.0.0 blog post.
Import from serialized meta data files (WL#7524) — This work by Dyre Tjeldvoll implements import for non-transactional storage engines such as MyISAM. Prior to 8.0, export and import is by copying .frm files along with the data files (e.g. .MYD and .MYI for MyISAM). In 8.0 this is replaced by new or adapted SQL statements which use the Data Dictionary, and provide better usability and uniformity.
New data dictionary: changes to DDL-related parts of SE API (WL#7743) — This work by Dmitry Lenev extends the SQL-layer code and parts of SE API which are related to opening tables and DDL. This work is needed to merge of the two – historically separate – data dictionaries and add support for crash safe DDL.
Improve string usage in DD code (WL#9468) — This work by Dyre Tjeldvoll introduces a typedef dd::string_type for all string usage in the DD code. This is code cleanup and enables performance schema memory instrumentation for string usage.
New data-dictionary: refactor .FRM to New DD code (WL#9540) — This work by Abhishek Ranjan removes redundant code related to converting FRM files to data dictionary information by changing both upgrade and non-upgrade code. This is code cleanup.
Information Schema
In 8.0.0 we introduced the new information schema implementation, see blog posts here and here. In 8.0.1 we extend this work by also covering stored programs, triggers, and events.
Implement INFORMATION_SCHEMA system views for SP/TRIGGERS/EVENTS (WL#9494) — This work by Gopal Shankar implements new system view definitions for the information schema tables TRIGGERS, ROUTINES, PARAMETERS, and EVENTS. The new views read metadata from the data dictionary tables and avoid creation of temporary tables in the same way as is done for TABLES, COLUMNS, etc.
Transparent Data Encryption
In 5.7 we introduced Tablespace Encryption for InnoDB tables stored in file-per-table tablespaces. This feature provides at-rest encryption for physical tablespace data files. In 8.0.1 we extend this work to include at-rest encryption of UNDO and REDO logs.
InnoDB: Support Transparent Data Encryption for Undo Tablespaces (WL#9289) — This work by Allen Lai provides encryption support for undo tablespaces. A new global, dynamic variable innodb_undo_log_encrypt=ON/OFF is used to enable and disable undo log encryption. Pages written to disk after setting innodb_undo_log_encrypt=ON are encrypted.
InnoDB: Support Transparent Data Encryption for Redo Log (WL#9290) — This work by Allen Lai provides encryption support for the redo log. A new global, dynamic variable innodb_redo_log_encrypt=ON/OFF is used to enable and disable undo log encryption. Pages written to disk after setting innodb_redo_log_encrypt=ON are encrypted.
BLOB
One of our goals for 8.0 is to support partial update of the JSON datatype. This implies partial BLOB update since the JSON datatype is stored as an InnoDB Binary Large Object (BLOB). In 8.0.0 we refactored the code for uncompressed BLOBs. In 8.0.1 we have refactored the code for compressed BLOBs.
InnoDB: Enable partial access of LOB using multiple zlib streams (WL#9263) — This work by Annamalai Gurusami changes the implementation of ROW_FORMAT=COMPRESSED from compressing a single stream to a sequence of many streams. This work is done to enable partial fetch for Binary Large Objects (BLOBs).
Thread Pool
We introduced the Enterprise Thread Pool in MySQL 5.5. In 8.0.1 we improve performance and efficiency related to accepting new connections.
Offload connection authentication and thd/net initialization from accept thread to tp worker threads for thread pool plugin (WL#7195) — This work by Thayumanavar Sachithanantha ensures that the acceptor thread spends maximum time listening for new connections. This means that the thread creation and other tasks should not be handled as part of accept event loop. Instead these tasks are delegated to thread pool worker threads that handle the client connections.
Replication
In 8.0.1 we deliver several replication enhancements. One highlight is that we significantly improve the slave applier performance by introducing writeset-based dependency tracking. We also improve performance by reducing the contention between receiver and applier replication threads. Another important change is a new infrastructure for proper monitoring of replication lag.
Writeset-based MTS dependency tracking on master (WL#9556) — This work by Vitor Oliveira introduces an option to the MySQL server that allows a user to choose whether to put information in the binary log that allows the slave to parallelize based on commit timestamps or transaction write sets. Parallelizing on write sets has potentially much more parallelism since it does not depend on the commit history, and as such, applying binary logs on a slave may utilize the underlying computing hardware (cpu cores) and ultimately this means that replication can become a lot faster. Our testing shows that we can apply binlog on the slave about 4 times faster, even for a single-threaded workload, which is the most difficult workload for Multi Threaded Slaves (MTS).
Reduce contention in IO and SQL threads (WL#8599) — This work by João Gramacho reduces the contention between receiver (I/O) and applier (SQL) replication threads. This causes the slave to keep up with a higher insert load on master and shows improvement up to 24% on Sysbench RW and up to 64% on Sysbench Update Index.
Infrastructure for GTID based delayed replication and replication lag monitoring (WL#7319) — This work by Maria Couceiro implements the infrastructure needed to properly monitor the replication lag. This work introduces two new timestamps that are associated with each transaction (not each event or statement) in the binary log: The original_commit_timestamp is in microseconds since the epoch when the transaction was committed on the original master, and the immediate_commit_timestamp is in microseconds since the epoch when the transaction was committed on the immediate master.
Performance schema tables to monitor replication lags and queue (WL#7374) — This work by Maria Couceiro adds performance schema tables for the purpose of showing replication delays in a reliable and well defined way. The table replication_connection_status has updated information on the last transaction queued in the relay log, as well as on the transaction currently being queued on the relay log. The table replication_applier_status_by_coordinator has updated information on the last transaction written to the buffer of a worker, as well as on the transaction currently being processed by the coordinator. The table replication_applier_status_by_worker has updated information on the last transaction applied by the worker, as well as on the transaction currently being applied. The information presented in each of these tables contain the transaction’s GTID, commit timestamps, processing stage timestamp, and the timestamp of the completion.
Add a new variable binlog_expire_logs_seconds (WL#9237) — This work by Neha Kumari adds a global server variable binlog_expire_logs_seconds in addition to the existing expire_logs_days variable. The purpose is to facilitate finer grained retention policies of binary logs than the current day granularity.
Delayed Replication: GTID based and relative to immediate master commit (WL#7318) — This work by Maria Couceiro improves how “delay” is defined and calculated for delayed replication. This work relies on a new timestamp in the binary log, the immediate_commit_timestamp, which is the number of microseconds since epoch when the transaction was written to the binary log of the immediate master. This means that the delay is no longer computed per-event, it is now applied per-transaction.
Add RESET MASTER TO x to allow specification of binlog file number (WL#9110) — This work by Neha Kumari modifies the RESET MASTER command to accept an argument which specifies the index of the new binary log file in use. The purpose is to simplify failover procedures by replacing FLUSH BINARY LOGS + PURGE BINARY LOGS TO with a single RESET MASTER command. Thank you to Daniël van Eeden for the code contribution in Bug#77482!
Correct recovery of DDL statements/transactions by binary log (WL#9175) — This work by Andrei Elkin implements support for correct recovery for DDL transactions based on the binary log data. In the context of the new data-dictionary it becomes possible to do metadata changes and writing to binary log as a single transaction by using the 2-phase commit protocol.
MSR: per-channel replication filters (WL#7361) — This work by Daogang Qu adds replication filtering to a multi-source slave (MSR). This makes it possible to filter out the execution of selected replicated data from a specific channel. Until now the replication filters have been global, applicable to all channels.
RBR: extended table metadata in the binary log (WL#4618) — This work by Libing Song extends the table metadata that is written to the binary log in row based logging. The extended metadata serves two major purposes: Slave needs the metadata to transfer data smoothly when its table structure is different from master’s. External software needs the metadata to decode row events and store the data into external databases.
Group Replication
We introduced Group Replication in MySQL 5.7.17. In 8.0.1 we add support for transaction savepoints to group replication.
Transaction savepoint support (WL#9837) — This work by Aníbal Pinto improves Group Replication by adding support for SQL transaction savepoints. This includes support for SAVEPOINT identifier, ROLLBACK TO SAVEPOINT identifier, and RELEASE SAVEPOINT identifier.
Performance Schema
In 8.0.0 we added support for aggregated counts of error messages and introduced performance schema indexes. In 8.0.1 we add two more commonly requested features, monitoring query response times and dependency graph for row locks.
Histograms (WL#5384) — This work by Marc Alff provides histograms of statements latency, for the purpose of better visibility of query response times. This work also computes “P95”, “P99” and “P999” percentiles from collected histograms. These percentiles can be used as indicators of quality of service.
DATA LOCKS (WL#6657) — This work by Marc Alff instruments data locks in the performance schema. When transaction A is locking row R, and transaction B is waiting on this very same row, B is effectively blocked by A. The added instrumentation exposes which data is locked (R), who owns the lock (A), and who is waiting for the data (B).
Persistent Configuration Variables
In 8.0.0 we introduced the SET PERSIST command which works like SET GLOBAL but in addition persists global, dynamic variables. This avoids losing the new value upon a server restart. We also introduced a new table variables_info in performance schema. This table stores the variable name, where the current value came from, and min/max values. In 8.0.1, based on community feedback, we have added the RESET PERSIST command and extended variables_info with who made the change and when it happened.
SET PERSIST capture user + timestamp (WL#9720) — This work by Satish Bharathy extends the SET PERSIST command introduced in 8.0.0 with the user name and the time of the last configuration change.
RESET PERSIST (WL#9763) — This work by Satish Bharathy adds the RESET PERSISTcommand as the reverse of SET PERSIST. The RESET PERSIST command has the semantic of removing the configuration variable from the persist configuration, thus converting it to have similar behavior as SET GLOBAL.
C Client API
Client interface for reading the replication stream (WL#7672) — This work by Ramil Kalimullin extends libmysql’s C API with a stable interface for getting replication events from the server as a stream of packets. The purpose is to avoid having to call undocumented APIs and package internal header files in order to implement binlog based programs like the MySQL Applier for Hadoop.
Security
In 8.0.0 we introduced SQL Roles. In 8.0.1 we build upon this work and provide fine grained system privileges as an alternative to the SUPER privilege. 8.0.1 also delivers better protection against brute force attacks on user passwords.
Pluggable dynamic privileges (WL#8131) — This work by Kristofer Älvring provides a service to easily register new, granular global privileges with the server at runtime. It provides an easy way to GRANT and REVOKE these privileges through SQL and programmatically check if they’re granted or not. This work also defines a set of new granular privileges for various aspects of what SUPER is used for today. New privileges in 8.0.1 are: FIREWALL_ADMIN, FIREWALL_USER, AUDIT_ADMIN, SYSTEM_VARIABLES_ADMIN, ENCRYPTION_KEY_ADMIN, BINLOG_ADMIN, VERSION_TOKEN_ADMIN, ROLE_ADMIN, REPLICATION_SLAVE_ADMIN, CONNECTION_ADMIN, GROUP_REPLICATION_ADMIN.
Introduce a delay in authentication process based on successive failed login attempts (WL#8885) — This work by Harin Vadodaria introduces a delay in the authentication process based on consecutive unsuccessful login attempts. This will slow down brute force attacks on user passwords. It is possible to configure the number of consecutive unsuccessful attempts before the delay is introduced and the maximum amount of delay introduced. This is done as a community plugin.
Component Service Registry
In 8.0.0 we introduced the Component Service Registry, the new plugin infrastructure for MySQL. In 8.0.1 we make it possible for old plugins to access the new service registry.
Allow plugins to access the component registry (WL#4989) — This work by Georgi Kodinov provides a plugin service API for the old plugins to access the registry and its services. This is needed to allow gradual migration of functionality from the old plugin infrastructure to the new one.
Server QA
We continue to maintain and improve the MySQL Test Run (MTR), the test infrastructure and test suites that shipped together with MySQL. New in 8.0.1 is that the MTR documentation is part of the source code documentation. See latest MySQL Source Code Documentation.
Move MTR documentation to Doxygen (WL#9541) — This work by Pavan Naik moves the MTR documentation from current infrastructure to the source code in Doxygen format.
Implement no-skip for daily and weekly MTR runs (WL#9547) — This work by Mohit Joshi introduces the --no-skip option in the default.daily and default.weekly files to ensure all the daily and weekly tests are run without any skip.
Remove *.require files (WL#9711) — This work by Pavan Naik removes the *.require files and replaces the check in corresponding inc files. This avoids the creation of a temporary file and comparison between the temporary and require files.
Migrate main suite to run with innodb (part 14) (WL#9489) — This work by Viswanatham Gudipati is another increment in the overall work to migrate the main suite to run with the InnoDB storage engine (used to be MyISAM). This work makes changes to the main.group_by.test and to auto_inc tests.
Migrate few “engine/funcs” tests to suite “parts” (WL#9502) — This work by Mohit Joshi rearranges partitioning tests with respect to which suites they are in based on the move in 8.0 to only support native partitioning.
Make –fail-check-testcase ON by default (WL#9492) — This work by Deepa Dixit ensures that a test fails if the check-testcase fails. In addition, the list of tests that fail with --fail-check-testcase are either fixed to run with --fail-check-testcase or if failure can’t be avoided, then are modified to not run with --fail-check-testcase.
Deprecation and Removals
Deprecate support for non-native partitioning (WL#9457) — This work by Sivert Sørumgård removes the support for non-native partitioning in 8.0.
Deprecate and remove temp-pool (WL#8396) — This work by Jon Olav Hauglid removes the –temp-pool setting in 8.0. The setting was introduced in MySQL 3.23 to compensate for a Linux discrepancy. The issue at hand has been fixed in all supported Linuxes, so there is no need for this setting anymore.
Deprecate and remove the replace utility (WL#9874) — This work by Jon Olav Hauglid removes the replace utility in 8.0. The replace utility program changes strings in place in files or on the standard input. This utility is not used by MySQL internally and it is not a natural part of MySQL.
Remove PROCEDURE ANALYZE (WL#4745) — This work by Gleb Shchepa removes the PROCEDURE ANALYZE clause in MySQL’s SQL grammar in 8.0. The PROCEDURE ANALYZE syntax is an anachronism and almost unused non-standard syntax extension. The functionality can be reimplemented as a stored procedure for potential users.
Deprecate and remove the \N synonym of NULL (WL#7247) — This work by Gleb Shchepa removes the \N synonym of NULL in 8.0. The \N synonym for the NULL was a non-standard SQL syntax extension. Historically, the feature was added to save space in the in mysqldumpoutput. With current versions of mysqldump, this is not used. This work does not affect the \N feature of the input/output file format of code>SELECT INTO and LOAD DATA statements. See also blog post here.
Deprecate and remove DTrace probes (WL#9581) — This work by Steinar Gunderson removes the DTrace probes in MySQL. The probes were added in 2008. There are a few very basic probes (e.g. number of rows fetched and number of index lookups) and little user take up of this feature. We decided to remove it to improve MySQL maintainability.
Do not build/package/test embedded server (WL#9816) — This work by Tor Didriksen removes support for the libmysqld embedded server in 8.0. There is almost no use of this feature and we have removed it to improve MySQL maintainability and overall MySQL binary size.
REMOVE INFORMATION_SCHEMA STATUS tables in MySQL 8.0 (WL#8057) — This work by Marc Alff removes the INFORMATION_SCHEMA tables SESSION_STATUS, SESSION_VARIABLES, GLOBAL_STATUS, GLOBAL_VARIABLES, and the system variable show_compatibility_56. The functionality is still provided in PERFORMANCE_SCHEMA and SHOW commands. See Migrating to Performance Schema System and Status Variable Tables.
Changed Defaults
Change default query_cache_size to zero (WL#9817) — This work by Abhishek Ranjan sets the query_cache_size to zero by default. In MySQL 5.6 changed the default query_cache_size to 1M, with query_cache_type to OFF. We now also set the query_cache_size to 0 because the Query cache mutex is still acquired when the size is non-zero.
