這是歷史版本頁面 — 看 MySQL (64-bit) 最新版本

想學資料庫先裝哪套?MySQL 能幫你做到什麼

MySQL (64-bit) 軟體圖示 MySQL (64-bit) 8.0.22 (64-bit) 資料更新 2020-10-19 閱讀約 6 分鐘

你正在架一個網站、寫一支會存資料的程式,或學校作業要用到資料庫。你上網查「資料庫 軟體」,跑出一堆名字,每個看起來都很專業,但你其實只想知道:裝哪一套可以趕快把資料存進去、把資料撈出來,不要卡在安裝和設定。你怕選錯,更怕裝了之後才發現不適合,又要重來。

很多人第一個念頭是用 Excel 或 Google 試算表硬撐,但資料一多、要同時讓好幾個人查詢、要寫條件篩選的時候,試算表就開始卡。另一條路是直接租雲端資料庫,但每個月要付錢,對還在學習或開發階段的人來說負擔太大。這類資料庫軟體的切入點是:給你一套在本機就能跑的關聯式資料庫,用 SQL 指令跟它溝通,先解決「有地方存資料」這個根本問題。

01MySQL 到底是做什麼用的?

它是一套關聯式資料庫管理系統,用來儲存、管理、查詢資料。你可以把它想成一個放在電腦裡的資料倉庫,透過 SQL 指令建立資料表、寫入資料、下條件查詢。它本身沒有圖形介面,安裝完之後是背景服務,要另外裝管理工具才能看到資料內容。

02我完全沒碰過資料庫,這套軟體適合入門嗎?

適合,但要有心理準備。它主要透過命令列操作,你至少要會基本的 SQL 語法,例如 CREATE TABLE、SELECT、INSERT 這些指令。官方文件寫得很完整,網路上教學資源也很多,只是學習曲線比圖形介面的工具陡一些。如果你完全不想碰指令,可以搭配 MySQL Workbench 這類圖形工具使用。

03它跟 Excel 有什麼差?什麼時候該換成資料庫?

Excel 適合幾千筆以內、單人編輯、不需要複雜關聯的資料。當資料量變大、多人同時讀寫、或你要做跨表格查詢的時候,Excel 會明顯變慢且容易出錯。MySQL 用 SQL 處理查詢,效能穩定,也支援多人同時連線,適合網站、應用程式這類需要頻繁讀寫資料的場景。

04安裝過程會不會很複雜?

安裝本身不複雜,執行安裝檔、按幾個下一步就裝好了。比較需要花時間的是安裝後的設定,包括資料庫帳號密碼、存取權限、連線埠這些。官方文件有提到,安裝時可以設定資料庫選項、定義存取權限、指定儲存方式。如果你只是想先跑起來,用預設值就可以了。

05它有沒有圖形介面可以用?

軟體本身只有命令列介面,但官方文件列出了幾個第三方圖形工具,包括 phpMyAdmin、MySQL Workbench、Navicat。這些工具可以讓你用滑鼠建立資料表、執行查詢、看效能狀態,不用背指令。其中 MySQL Workbench 是 Oracle 出的免費工具,跟 MySQL 搭配使用的人很多。

06我寫程式的語言跟它合得來嗎?

官方文件說它支援多種程式語言,並提供對應的連接器,例如 Java 用 MySQL Connector/J、Python 用 MySQL Connector/Python。也就是說,你只要照官方文件把對應的驅動程式裝好,就可以從程式裡連到資料庫下 SQL 指令。PHP、C# 這些常見語言也都有社群提供的連線方式。

07這套軟體是免費的嗎?

它分成兩個版本:Community Edition 免費且開放原始碼,Enterprise Edition 要訂閱付費。免費版涵蓋大部分日常功能,但官方文件提到,即時分析、企業級技術支援這類進階功能只有在付費版才有。一般學習、開發、小型專案用免費版就夠了。

08我只會 Windows,這套軟體在我的電腦上跑得起來嗎?

可以。官方支援 Windows 7 到 Windows 11 的 64 位元系統,也支援 macOS 和 Linux。安裝時要注意你的系統是 64 位元,硬碟空間和記憶體要看資料庫大小決定,官方文件說需求會依版本和資料量而不同。

09介面是中文的嗎?

不是。軟體本身的介面是英文,安裝過程和命令列操作都是英文。如果你對英文介面不熟悉,操作上會多一層障礙。不過圖形工具 MySQL Workbench 的介面也是英文,這點要先有心理準備。網路上有大量中文教學,可以邊看邊學。

10我只是想存一些個人資料,這套會不會太重?

如果你的需求是單機、單人、資料量不大,SQLite 這類輕量資料庫可能更適合。SQLite 不需要安裝伺服器、不需要設定帳號密碼,把資料庫存成一個檔案就能用。MySQL 需要背景服務持續執行,對純個人用途來說確實比較重,但如果你之後要學網站開發,遲早會用到它。

11我聽說微軟也有免費的 SQL Server Express,跟它比起來呢?

SQL Server Express 是微軟出的免費資料庫,介面是中文的,圖形工具 SSMS 也比較完整,對 Windows 使用者來說上手門檻較低。MySQL 的優勢是跨平台、開源、社群龐大,而且網路上教學資源非常多。兩套都是免費的,你可以先裝 MySQL 試試,不習慣再換 SQL Server Express。

12這套軟體是不是很久沒更新了?

不是。根據收錄的版本紀錄,它從 2011 年至今持續有新版釋出,最近一年內更新了 3 次,最近兩年內更新了 7 次,屬於持續維護中的軟體。開發商是 Oracle,背後有商業公司在維護,不用擔心專案突然停擺。

下載與官方連結

前往官方網站 下載 MySQL (64-bit)

mysql-installer-community-8.0.22.0.msi · 405 MB · 連結指向軟體原廠

版本紀錄

再看 5 筆

看完整版本清單

這一版改了什麼

What's new in this version:

Fixed:
- InnoDB: Code related to transaction support for histogram sampling was removed, including related assertion code that caused test failures. Transaction support is not required for histogram sampling. (Bug #31787736)
- InnoDB: Encryption information was not set for redo log archive log writer thread write operations. (Bug #31690196)
- InnoDB: The TTASEventMutex::exit function was optimized for ARM64
- InnoDB: InnoDB failed to compile with the DISABLE_PSI_RWLOCK CMake option enabled. (Bug #31578289)
- InnoDB: The transaction isolation level, which is set to READ UNCOMMITTED for histogram sampling to avoid unnecessary lookups of old record versions, was not reset after the sampling operation completed. (Bug #31564407)
- InnoDB: A query that updated the clustered index of an internal temporary table returned an incorrect result. The modified pages of the clustered index were not added to the flush list resulting in lost changes when the modified pages were evicted from the buffer pool. (Bug #31560679)
- References: This issue is a regression of: Bug #29207450.
- InnoDB: A build dependency on the Boost library defined for the TempTable storage engine was removed. (Bug #31505048)
- InnoDB: A workaround was implemented to handle a Clang compiler issue in 32-bit builds that causes the ATOMIC_LLONG_LOCK_FREE value to be defined as “sometimes lock-free” while __atomic_always_lock_free returns true for the same type on the same platform. (Bug #31504609)
- InnoDB: A REDUNDANT row format table created in an earlier version of MySQL, where the row format was not defined explicitly, permitted the addition of an index that exceeded the REDUNDANT row format index column size limit. (Bug #31479542, Bug #99791)
- InnoDB: A DML operation on a column defined with a multi-valued index caused a failure. (Bug #31479282)
- InnoDB: A failure occurred during master key rotation. An undo tablespace in-memory object was freed prematurely. (Bug #31467626)
- InnoDB: Unused physical read ahead code was removed from the parallel read interface. (Bug #31429385)
- InnoDB: A master key rotation operation failed to skip an undo tablespace that was already truncated, which lead to an assertion failure when shutting down the server. (Bug #31400195)
- InnoDB: After importing a tablespace for a page-compressed table, pages were no longer compressed, and INFORMATION_SCHEMA.INNODB_TABLESPACES metadata incorrectly indicated that pages were compressed. The table's compression information was unavailable during the import operation. (Bug #31396947)
- InnoDB: A rollback and update operation after performing an instant DDL operation raised an assertion. (Bug #31391126)
- InnoDB: The log system (log_sys) sharded read-write lock caused a performance regression in CPU-bound workloads. (Bug #31389135)
- InnoDB: Compiling with the UNIV_ENCRYPT_DEBUG option enabled caused compilation errors. (Bug #31369540)
- InnoDB: DDL operations on a partitioned table could cause a failure. TABLE_SHARE and table instance objects were opened for all partitions unnecessarily. (Bug #31365127)
- InnoDB: After changing a VARCHAR column collation from utf8mb4 to utf8mb4_bin in an in-place ALTER TABLE operation and adding an index on the same column, a case-sensitive query on the VARCHAR column returned an incorrect result. The VARCHAR column collation was changed in the data dictionary but not in the in-memory table object. Consequently, the index created on the VARCHAR column used stale column information causing comparisons to use the previously defined collation. (Bug #31361838)
- InnoDB: An ALTER TABLE ... IMPORT TABLESPACE operation on a large encrypted and compressed table failed with a Page decompress failed after reading from disk error. The decryption operation did not use the encryption block size used during encryption. Also, the encryption process did not consider compressed length, while the decryption process decrypts data by compressed length only. (Bug #31313533)
- InnoDB: A failure occurred during a concurrent update operation. The failure was due to an invalid previous record value. (Bug #31205266, Bug #99286)
- InnoDB: Upgrade from MySQL 5.7 to MySQL 8.0 failed on an instance with a table created in a general tablespace and defined with a FULLTEXT index. The correct data dictionary space ID for table could not determined. (Bug #31154128, Bug #99211)
- InnoDB: The function used to process the SHOW ENGINE INNODB MUTEX statement was insufficiently isolated from other threads adding new mutexes concurrently. (Bug #31105262)
- InnoDB: Failure to call a buffer pool page I/O completion routine resulted in orphan buffer pool I/O write pages. (Bug #31073853)
- InnoDB: Numerous system temporary table pages at the tail of the buffer pool flush list caused a performance degradation. The flush_list_mutex was held while the flush list scan traversed over system temporary table pages. The flush list scan now excludes system temporary table pages. (Bug #31060470, Bug #98974)
- InnoDB: The buffer control block structure (buf_block_t) was freed while reducing the size of the buffer pool, causing an assertion failure. The fix for this bug also backports important aspects of the fix for Bug #20735882 / Bug #76343, and replaces the internal buf_block_is_uncompressed() function with the buf_pointer_is_block_field_instance() function. The buf_block_is_uncompressed() function returned false in too many cases, affecting OLTP query throughput. (Bug #31036301, Bug #31389823)
- InnoDB: Parallel read threads failed to respond to an explicit transaction interruption. (Bug #31016076)
- InnoDB: In session started with START TRANSACTION WITH CONSISTENT SNAPSHOT, a range query returned a truncated result. The end range flag was not reset at the beginning of the index read resulting in an aborted read and missing rows. (Bug #30950714, Bug #98642)
- References: This issue is a regression of: Bug #23481444.
- InnoDB: A full-text phrase search raised an assertion failure.
- References: This issue is a regression of: Bug #22709692.
- InnoDB: A failure occurred while attempting to initialize the system tablespace on a raw disk partition. Additionally, a INPLACE DDL operation on the raw-disk partition tablespace failed with an error instead of switching to the COPY algorithm. (Bug #30867065, Bug #98091)
- InnoDB: LOB purge code (lob::purge()) did not properly handle latches taken during B-tree mini-transaction (btr_mtr) commit and restore operations, which could lead to conflicts between B-tree and LOB mini-transactions. (Bug #30620011)
- InnoDB: A long running statistics calculation operation on a large table blocked other operations requiring access to the table's statistics, causing those operations to fail. A new statistics calculation mutex was introduced, which permits concurrent access table statistics.
- InnoDB: Two connections attempted to use the same transaction handler object resulting in a stalled query. (Bug #30594501)
- InnoDB: Shutting down the server with innodb_fast_shutdown setting greater than 0 raised an assertion failure. The assertion was caused by the presence of recovered transactions that were not yet rolled back. Assertion code was revised to ignore recovered transactions during a fast shutdown. Messages are now written to the error log when recovered transactions that are not rolled back are left behind by a fast shutdown. Slow shutdown now waits for recovered transactions to be rolled back. Various other shutdown logic improvements were implemented. (Bug #30226841)
- InnoDB: Dedicated log writer threads, introduced in MySQL 8.0.11, caused a CPU-bound performance regression on low-concurrency systems. To address this issue, the new innodb_log_writer_threads variable permits disabling dedicated log writer threads so that redo log records are written from the log buffer to the system buffers and flushed from the system buffers to the redo log files by each user thread, which is the behavior prior to the introduction of dedicated log writer threads. Other redo logging optimizations were implemented, including the removal of an unnecessary log closer thread that wasted CPU time, and optimizations to remedy too-aggressive checkpoint activity and excessive flush calls. The issues addressed by this fix also manifested in a LOAD DATA performance regression. (Bug #30088404, Bug #30003849)
- InnoDB: Restarting the server with an incorrect lower_case_table_names setting after a failure caused a hang condition. At startup, InnoDB waited for a transaction to roll back, but the rollback thread was not initiated due to a startup validation failure caused by the incorrect lower_case_table_names setting. (Bug #29833945)
- Replication: X Plugin could stop unexpectedly if a Group Replication notification was issued after a new X Protocol connection was made but before the session was created. The dispatcher thread that handles Group Replication notifications now checks that the session pointer is valid. (Bug #31742798)
- Replication: Group Replication's handling of memory allocation issues when adding transaction write sets has been improved. (Bug #31586243)
- Replication: You can now set the value of the gtid_purged system variable in a stored procedure, which was not previously permitted. You cannot set gtid_purged in a stored function. (Bug #31571427)
- Replication: While a remote cloning procedure was taking place on a joining member during distributed recovery, Group Replication considered the pre-cloning gtid_executed value of the joining member when identifying the common set of transactions that had been applied on all members. This meant that garbage collection for applied transactions from the group's set of certification information (shown as the count_transactions_rows_validating field in the Performance Schema table replication_group_member_stats) did not take place during the remote cloning procedure. If the remote cloning procedure took a long time, the certification information could therefore get too large to transmit to the joining member when it restarted after the remote cloning procedure, in which case an error was raised and the member was not able to join the group.
- To avoid this issue, Group Replication now considers only group members with ONLINE status when identifying the common set of transactions that have been applied on all members. When a joining member enters ONLINE state after distributed recovery, its certification information is updated with the certification information from the donor at the time when the member joined, and garbage collection takes place for this on future rounds.
- As a workaround for this issue in earlier releases, after the remote cloning operation completes, wait two minutes to allow a round of garbage collection to take place to reduce the size of the group's certification information. Then issue the following statement on the joining member, so that it stops trying to apply the previous set of certification information:
- RESET SLAVE FOR CHANNEL group_replication_recovery;
- Replication: It was possible for a group member that left the group due to a communication error to reconnect between auto-rejoin attempts while the auto-rejoin procedure was still ongoing, which left Group Replication unable to function on the member. Group Replication's error management and member status handling has now been corrected to prevent this situation. (Bug #31401797)
- Replication: When a replication source server shuts down and restarts, its MEMORY tables become empty. To replicate this effect to replicas, the first time that the source uses a given MEMORY table after startup, it logs an event that notifies replicas that the table must be emptied by writing a statement to the binary log to that effect. Previously, this was a DELETE statement, but it is now a TRUNCATE TABLE statement. A replica server also writes this statement to its own binary log when it shuts down and restarts. The statement is always logged in statement format, even if the binary logging format is set to ROW, and it is written even if read_only or super_read_only mode is set on the server. (Bug #29848785, Bug #95496)
- Replication: When the system variable session_track_gtids was set to OWN_GTID on a multithreaded replica, the replica’s performance would degrade over time and begin to lag behind the master. The cause was the buildup of the GTIDs recorded by the replica’s worker threads at each transaction commit, which increased the time taken by the worker threads to insert new ones. Session state tracking is now disabled for worker threads on a multithreaded replica. Thanks to Facebook for the contribution. (Bug #29049207, Bug #92964)
- Replication: When using row-based replication, the replica was allowed to use an invisible index when searching for rows to synchronize. (Bug #96148, Bug #30072179)
- Microsoft Windows: On Windows, build targets could fail if the build was on a file system root, such as R:/. (Bug #31315467)
- JSON: JSON_ARRAYAGG() did not always perform proper error handling. (Bug #31856260)
- JSON: JSON_OBJECT() did not always perform proper checking for NULL values. (Bug #31393934)
- The new WITH_SYSTEMD_DEBUG CMake option, if enabled, produces additional systemd debugging information, for platforms on which systemd is used to run MySQL. The default is OFF. (Bug #31788834)
- For RPM and Debian packages, client-side plugins were moved from the server package to the client package in MySQL 8.0.21. This could cause failures relating to LDAP authentication plugins when upgrading from 5.7 packages to 8.0 packages. Packaging adjustments were made to avoid this problem. (Bug #31782612)
- References: This issue is a regression of: Bug #31123564, Bug #31336340.
- The timestamp written for the ts key by the log_sink_json JSON-format error log sink did not have the same value as other timestamps in the same log message. (Bug #31749103)
- Kerberos authentication for the SASL LDAP authentication plugin incorrectly handled failure to acquire a ticket-granting ticket. (Bug #31727195)
- For some third-party libraries, enabling link-time optimization caused build failures. (Bug #31701553, Bug #100410)
- Printing an excessively long diagnostic message could cause the server to exit unexpectedly. (Bug #31686926)
- A page-compressed table was cloned as an uncompressed table. The associated tablespace object, which includes a compression flag, was not initialized prior to the cloning operation. (Bug #31677990, Bug #100243)
- Certain cases of successful LDAP authentication could cause the server to hang. (Bug #31661437)
- During transformation of a grouped query into a derived table, when the WHERE clause and the HAVING clause became part of the derived table, the condition count was not updated for the derived table. This resulted in reduced memory allocation while creating keys for ref access. (Bug #31661309)
- When a value was compared using LIKE with a table column not defined as one of the MySQL string types, the server sometimes did not raise the expected error. (Bug #31659015)
- The acquire_related() service function returned the default service in some cases when it should have returned an error. (Bug #31655906)
- In bootstrapping mode, certain multiple-statement transactions could cause unexpected server behavior. (Bug #31650096)
- A remote cloning operation checked for the availability of a plugin on the recipient that was removed from the donor instance previously. References to the uninstalled plugin had not been released. Error reporting issues related to plugin mismatches and availability were also addressed. (Bug #31639732, Bug #100244)
- MySQL Server Docker images did not expose the Group Replication recommended port (33061). (Bug #31627536)
- In debug builds, the server attempted to evaluate subqueries while creating a view. (Bug #31590301)
- References: This issue is a regression of: Bug #25466100.
- A condition using RAND() was not pushed down even in cases where it was safe to do so, that is when no windowing function or GROUP BY is in use. (Bug #31587575)
- While pushing conditions down to a derived table, a constant condition such as WHERE FALSE or WHERE TRUE was pushed down to the first table in the derived table, which is not necessary as the condition has nothing to do with the derived table. MySQL now avoids pushing constant conditions down to derived tables in such cases.
- In addition used tables are now updated for the condition that needs to be pushed down to the derived table, following code inspection revealing that this was not done after replacing the columns in the condition with the derived table expressions. (Bug #31587493)
- A query using WHERE column > (... IN (SELECT ...)) could sometimes trigger an assertion in the range optimizer. (Bug #31586906)
- References: This issue is a regression of: Bug #30473261.
- It was possible for ANALYZE TABLE to fail with Duplicate key error if a row was inserted in the interval between the check for the existence of the row and the execution of the insert, and the statistics table was updated concurrently. ANALYZE TABLE now ignores the error in this situation. (Bug #31582758)
- The range optimizer does not use the correct lock type after cloning the handler needed to perform merged scans, and instead used a read lock unconditionally. This resulted in various different side effects for different scenarios.
- For example, a SELECT with FOR UPDATE requests a write lock, but after cloning the handler for an index merge scan, the range optimizer requested a read lock which resulted in a mismatch. Similarly, for data dictionary tables, the lock type was set to LOCK_NONE due to the special handling required for such tables.
- To prevent this problem from occurring, we now ensure that the original lock type of the handler is always used in the cloned handler as well. (Bug #31582383)
- In some cases, a query using an ANY subquery gave an incorrect result when the subquery_to_derived optimizer switch was enabled. (Bug #31566339)
- When FALSE AND condition was simplified as FALSE, temporary table resources allocated for the condition were not always released afterwards. (Bug #31565009)
- A value equal to ULLONG_MAX could be inserted into a BIT(64) column, but not retrieved. (Bug #31564742, Bug #100053)
- While removing an unused window definition, a subquery that was part of an ORDER BY was not removed. The optimizer then tried to optimize the subquery without locking the tables. Now, when removing an unused window definition, the server cleans up any subqueries present as part of the definition. (Bug #31518806)
- References: This issue is a regression of: Bug #27062031.
- Added a missing error code translation from ICU U_REGEX_NUMBER_TOO_BIG to MySQL ER_REGEX_NUMBER_TOO_BIG. (Bug #31514995)
- Merging during filesort operations could fail to remove duplicates for queries that used DISTINCT. (Bug #31498664, Bug #99900)
- MySQL's internal DYNAMIC_STRING class formerly allocated memory in a linear fashion, that is, by a predetermined number of bytes. The class has been revised such that it now allocates memory exponentially, which should make operations such as repeated string appends more efficient. (Bug #31491799)
- LOCK_mutex mishandling could result in a memory leak. (Bug #31491146)
- A newly added collation was not added and could cause an unexpected exit on shutdown. (Bug #31470422)
- On Windows, file name reuse by the GetTempFileName() function could cause an assertion to be raised. (Bug #31468590)
- A LATERAL subquery was incorrectly converted into an antijoin. (Bug #31465717)
- NATURAL JOIN evaluation could inadvertently match hidden virtual columns created by functional indexes. (Bug #31463511, Bug #99807)
- Sort keys for string hash join keys using more than 1024 bytes were not handled correctly by the server. (Bug #31437753)
- The server attempted to delete from a view whose definition included HAVING when the HAVING clause was constant and evaluated as true even though a view with HAVING as part of its definition should not be updatable. (Bug #31429865)
- Privilege requirements were checked incorrectly for the INFORMATION_SCHEMA.USER_ATTRIBUTES table. (Bug #31427410)
- When the internal function replace_index_subquery() failed, the server still attempted to create iterators for the affected subquery. Now the function raises a clear error instead. (Bug #31427072)
- A query using WHERE NOT EXISTS (SELECT const FROM table WHERE column=FROM_UNIXTIME(value) was not handled correctly. (Bug #31425664)
- In some cases, key_hint handling was improperly applied to derived and internal temporary tables. (Bug #31424455)
- Re-execution of prepared INSERT statements could fail for inserts through a view. (Bug #31417951)
- JSON scalar evaluation could enter an infinite loop. (Bug #31406724)
- The user_attributes column in mysql.user table rows could be affected incorrectly by partial revokes. (Bug #31405985)
- Improper window function initialization could cause a server exit. (Bug #31389573, Bug #31437834)
- Sensitive LDAP authentication plugin system variables now display as asterisks when retrieved in SQL statements. (Bug #31388444, Bug #31391864)
- mysql-test-run.pl tests under no-threads connection handling failed with ASAN builds due to improper resource group initialization. This has been fixed. Thanks to Xiaoyu Wang, Tencent Technology for the contribution. (Bug #31378900, Bug #99609)
- Using the authentication_ldap_simple authentication plugin with SSL could cause a segmentation fault during shutdown. (Bug #31364927)
- Killing a query could raise spurious assertions in the hash join iterator. (Bug #31361354)
- In some cases, an outer reference that was not LATERAL was not marked as read-only as expected. (Bug #31359965)
- A failure occurred when upgrading from MySQL 5.7 to MySQL 8.0 due to invalid references to orphaned events (events for which a database no longer exists). The server now fails with an appropriate error messages when orphaned events are encountered during upgrade. Error messages for orphaned stored routines were also revised. (Bug #31335554)
- Enabling the create_admin_listener_thread system variable could cause a server exit during startup. (Bug #31335279)
- After ALTER TABLE to add an expression default to a column, the first insert inserted a value as if the expression had been evaluated at alter time and not insert time. (Bug #31330789, Bug #99513)
- The LDAP authentication plugins did not properly compare the user-supplied authentication method against the permitted methods. (Bug #31320532)
- Certain views could cause a following USE statement to result in an unexpected server exit. (Bug #31311312)
- When a filesort sorted a buffer and LIMIT was active, it first sorted all rows and then discarded those that did not fit within the limit, which required sorting many rows that were certain to be discarded later. Now the optimizer sorts only the rows actually needed. Internal testing shows that this change can speed up the sort phase for a simple string sorting benchmark (as measured by EXPLAIN ANALYZE) by up to 15%. (Bug #31303537)
- A dynamic range scan runs the range optimizer for each row fetched from the first table in a join to determine whether a range scan can be picked for the second table using the value available from that row. If the row contains no usable indexes, a table scan may be chosen instead. For the query giving rise to this issue, a table scan is chosen once, followed by a range scan on a non-covering index, and the dynamic range iterator has two read sets which are used for both these cases. One of these, used for the table scan, includes the base columns of generated columns required for processing the query; the other read set does not include the base columns in the read set used for range scans. This is because, for covering indexes, the read set should not include base columns to avoid adding unneeded columns by hash join or batched key access. The issue arose because the second read set was also used for a non-covering index, which resulted in an assert.
- To prevent this from happening, when initializing a table read set in the dynamic range iterator, we now make sure that it includes the base columns when the range optimizer picks a non-covering index. (Bug #31280526)
- References: This issue is a regression of: Bug #30417361.
- It was possible to insert an out-of-range value for a TIMESTAMP if it included a timezone offset. (Bug #31239157)
- The keyring_hashicorp keyring plugin did not limit the size of keys for key operations. (Bug #31205715)
- Configuring with -DWITH_ZSTD=system failed for older versions of the zstd library. CMake now checks the zstd version and requires at least 1.0.0 for compilation, 1.2.0 to run compression checks. (Bug #31174920, Bug #99241)
- In some cases, a SELECT that obtained status variable information from Performance Schema tables and that included a sort by a column containing temporal values was not handled correctly. (Bug #31168097)
- In some cases, ROUND() and TRUNCATE() did not return the data type of their first arguments as expected. This fix insures that return types from these functions follow these rules, where the first argument is of the type shown:
- For any integer type, the return type is BIGINT.
- For any floating-point type or any non-numeric type, the return type is DOUBLE.
- For DECIMAL, the return type is also DECIMAL.
- The type attributes for the return value are also copied from the first argument, except in the case of DECIMAL, when the second argument is a constant value.
- When the desired number of decimal places is less than the scale of the argument, the scale and the precision of the result are adjusted accordingly. In addition, for the ROUND() function, the precision is extended by one place to accomodate rounding that increases the number of significant digits. If the second argument is negative, the return type is adjusted such that its scale is 0, with a corresponding precision.
- For more information, see the description of the ROUND() function. (Bug #31128028)
- A SELECT ... FOR SHARE statement now only requires the SELECT privilege. Previously, the SELECT privilege was required with at least one of the DELETE, LOCK TABLES, or UPDATE privileges. (Bug #31096384, Bug #99101)
- A semijoin strategy was chosen for the join of a correlated subquery having a LIMIT clause and requiring a row other than the first, which caused the LIMIT clause to be ignored and invalid rows to be returned. Now, when LIMIT used with this type of join specifies a row other than the first row, or more than one row, the semijoin strategy is no longer employed. (Bug #31096309)
- After the fix for Bug #81009, privilege checks for truncating Performance Schema tables were too restrictive when read_only or super_read_only were enabled, causing truncation to fail even for users with appropriate table privileges. (Bug #31080309, Bug #99072)
- References: This issue is a regression of: Bug #81009.
- ORDER BY did not work as expected for queries with ROLLUP in which window functions were also used. (Bug #31073133)
- Some INSERT statements were not handled correctly. (Bug #31072198)
- Date interval calculations checked for overflow but not underflow. Now they check for both. (Bug #31054071)
- Regular expression functions such as REGEXP_LIKE() yielded inconsistent results with binary string arguments. These functions now reject binary strings with an error. (Bug #31031886, Bug #98951, Bug #31031888, Bug #98950)
- If an XA prepared transaction rollback XID was incorrectly formatted, the transaction remained in recovered state for XA COMMIT and XA ROLLBACK statements (or raised an assertion for debug builds) rather that reporting an error. (Bug #31030205)
- Database-level privileges inherited through a role were not handled properly for database names that contained wildcard characters. (Bug #31013538, Bug #98876)
- When the --local option was given, mysqlimport mishandled the MYSQL_OPT_LOAD_DATA_LOCAL_DIR option for mysql_options() so that it had no effect. (Bug #31001550)
- Certain prepared statements could cause an unexpected server exit. (Bug #30943963)
- OPTIMIZE TABLE for MyISAM tables could cause table size to increase and query performance to decrease. REPAIR TABLE for MyISAM tables could cause the Table is already up to date status produced by a previous OPTIMIZE TABLE to be lost. (Bug #30869674, Bug #98511, Bug #29755517)
- mysqlpump object validation included objects in excluded databases. (Bug #30819012)
- Inserting a TIMESTAMP value having a timezone offset which also had a zero for the month, day, or both, led to an assert. Such a value should be and is now rejected, regardless of the sql_mode setting. (Bug #30786762)
- References: See also: Bug #31239157.
- Comparison of a TIME value with NULL in some cases raised an assertion. (Bug #30324587)
- References: This issue is a regression of: Bug #25949639.
- LDAP authentication plugins enforced CA verification incorrectly, which could result in use of an incorrect CA. (Bug #30220357)
- ORDER BY queries were not executed correctly when sort_buffer_size and max_sort_length were set to values which caused the internal limit on the maximum number of keys allowed per sort buffer to be set to 0. (Bug #30175483)
- A large number of nested arguments in full-text search query caused an error. (Bug #29929684)
- A potential misreporting of memory use by the Performance Schema has been corrected. (Bug #29912403)
- When explicit_defaults_for_timestamp was disabled and a NULL was inserted into a generated column declared as TIMESTAMP NOT NULL, the server would attempt to convert the inserted value to CURRENT_TIMESTAMP. Such an insertion is now rejected with ER_BAD_NULL_ERROR. (Bug #29449518)
- The SET_VAR hint did not accept a floating point value specified as a system variable setting. (Bug #29349748)
- Previously, when NULL was used as the format argument to STR_TO_DATE(), irrelevant warnings were printed. Now, when NULL is passed to it, the function returns NULL. (Bug #27265863)
- In some cases, incorrect use of IS NULL generated multiple warnings about invalid arguments. (Bug #27264652)
- Resolving an ORDER BY column that referred to a SELECT list column from a derived table was not performed correctly when executing certain prepared statements. (Bug #26808862)
- When using EXPLAIN on a multi-table UPDATE statement in which a generated column was referenced in a condition, the output always showed the table containing this column as being updated, whether the table was actually updated or not. (Bug #22671310)
- An assertion could be raised when the SQL layer passed incorrect information to InnoDB about the type of operation to be performed on a temporary table. (Bug #22503696)
- This construct works for base tables to insert a row using all default values but failed for views:
- INSERT INTO name () VALUES ();
- In some cases, the server issued an error when an invisible index was used in an index hint even when the use_invisible_indexes optimizer switch was not set to OFF. (Bug #100024, Bug #31550839)
- When range values specified in a predicate are not compatible with the data type of the column with which the values are compared, the range optimizer rounds off the range values and assigns certain flags so that it does not exclude rows that qualify for the range because of rounding. In the specific query that triggered the reported issue, a column named id of type INT was tested using id NOT IN (-0.1, 0.1), and the values being tested are rounded to integers, with the predicate thus being treated as NOT IN (0,0). The optimizer then treats this as the intervals id < 0 and 0 < id < 0, but in this case it also set a flag to a value that indicated that reads should begin following rows containing 0 for the value to be compared. Now in such cases, the flag is set in such a way that the values which have been rounded are treated correctly. (Bug #98826, Bug #30988735)
- For a view based on a join having an updatable part and one that was not, the error message generated when attempting to update a column of this view that was not updatable referenced the source table or view instead of the view actually named in the offending UPDATE statement. (Bug #80655, Bug #22891840)