The world`s most popular open-source relational database management system

MySQL

MySQL 5.7.32

  -  487 MB  -  Open Source
  • Latest Version

    MySQL 8.0.40.0

  • Operating System

    Windows XP64 / Vista64 / Windows 7 64 / Windows 8 64 / Windows 10 64

  • User Rating

    Click to vote
  • Author / Product

    Oracle / External Link

  • Filename

    mysql-installer-community-5.7.32.0.msi

  • MD5 Checksum

    d41d8cd98f00b204e9800998ecf8427e

Sometimes latest versions of the software can cause issues when installed on older devices or devices running an older version of the operating system.

Software makers usually fix these issues but it can take them some time. What you can do in the meantime is to download and install an older version of MySQL 5.7.32.


For those interested in downloading the most recent release of MySQL or reading our review, simply click here.


All old versions distributed on our website are completely virus-free and available for download at no cost.


We would love to hear from you

If you have any questions or ideas that you want to share with us - head over to our Contact page and let us know. We value your feedback!

  • MySQL 5.7.32 Screenshots

    The images below have been resized. Click on them to view the screenshots in full size.

    MySQL 5.7.32 Screenshot 1
  • MySQL 5.7.32 Screenshot 2
  • MySQL 5.7.32 Screenshot 3
  • MySQL 5.7.32 Screenshot 4
  • MySQL 5.7.32 Screenshot 5

What's new in this version:

Added or Changed:
- LOCK TABLES privilege checking for views was improved

Bugs Fixed:
- 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
- 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
- InnoDB: A failure occurred during a concurrent update operation. The failure was due to an invalid previous record value
- InnoDB: The function used to process the SHOW ENGINE INNODB MUTEX statement was insufficiently isolated from other threads adding new mutexes concurrently
- 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
- 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.
- InnoDB: A full-text phrase search raised an assertion failure. Thanks to TXSQL (Tencent MySQL) for the contribution
- 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. Thanks to Kamil Holubicki for the contribution.
- InnoDB: Two connections attempted to use the same transaction handler object resulting in a stalled query
- 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.
- 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.
- Certain cases of successful LDAP authentication could cause the server to hang
- In bootstrapping mode, certain multiple-statement transactions could cause unexpected server behavior
- Sensitive LDAP authentication plugin system variables now display as asterisks when retrieved in SQL statements
- 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
- Some INSERT statements were not handled correctly
- Certain prepared statements could cause an unexpected server exit
- mysqlpump object validation included objects in excluded databases
- LDAP authentication plugins enforced CA verification incorrectly, which could result in use of an incorrect CA
- 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.
- A large number of nested arguments in full-text search query caused an error
- 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.
- 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