這是歷史版本頁面 — 看 MySQL (32-bit) 最新版本
裝了 MySQL 之後不知道怎麼開始?它能做什麼、該不該用
你剛把 MySQL 裝好,打開黑色的命令提示字元視窗,輸入指令後卻不確定下一步要做什麼。或者你正在架一個網站、寫一支小程式,需要一個地方存放資料,聽別人說「用 MySQL 就好」,但你真的打開它之後,才發現跟想像中完全不一樣——沒有漂亮的視窗介面,只有一行一行的文字指令,你甚至不知道該從哪個指令開始。
一般人遇到這種狀況,直覺是去裝一個圖形介面工具,或是上網找教學影片。但問題往往不是「不會操作」,而是「不確定 MySQL 到底能幫你做到什麼程度」。它不像一般應用程式打開就能用,它是一套資料庫伺服器,需要你先理解「資料庫」的概念,才知道怎麼讓它為你工作。這類工具的核心切入點,是讓你把資料有結構地存起來、隨時查得回來,而不是像 Excel 那樣手動管理。
01MySQL 到底是做什麼用的?
它是一套關聯式資料庫管理系統,用來存放、管理、查詢資料。你可以把它想成一個「有結構的倉庫」——先把資料依照表格、欄位、關聯的方式規劃好,之後用 SQL 指令把資料寫進去或讀出來。網站會員資料、訂單紀錄、文章內容,這類需要頻繁讀寫的資料,都適合交給它處理。
02這套軟體一定要用指令操作嗎?
它本身主要透過命令提示字元操作,沒有內建圖形介面。但官方文件提到,可以搭配 phpMyAdmin、MySQL Workbench、Navicat 這些第三方工具,用滑鼠點一點就能建立表格、執行查詢、看效能狀態。如果你不習慣打指令,裝一個圖形工具會比較好上手。
03我原本用別的資料庫,可以把資料搬過來嗎?
官方說明指出,它提供工具和公用程式,可以從 Oracle、SQL Server、PostgreSQL 這些其他資料庫系統遷移過來。不過實際遷移的過程會牽涉到資料型別轉換、編碼設定等細節,建議先找官方文件確認支援的版本和步驟,再動手轉移。
04它支援寫入複雜的邏輯嗎?例如自動計算或觸發事件?
支援。官方文件明確列出它支援預存程序、觸發器和函數,意思是你可以把一段常用的 SQL 邏輯存起來重複呼叫,也可以在特定事件發生時自動執行某段程式。這對需要自動化處理資料的應用程式來說,是很常用的功能。
05資料放進去之後,要怎麼防止別人亂看?
它提供使用者認證、存取控制和加密機制。你可以建立不同的使用者帳號,分別設定他們能看哪些資料庫、能執行哪些操作,也可以啟用加密來保護傳輸中的資料。不過這些都需要你自己去設定,預設狀態下並不會自動幫你做好完整的權限控管。
06我完全沒寫過程式,適合用這套軟體嗎?
官方文件提到,要有效使用 MySQL,需要具備 SQL 語言的基本概念。如果你完全沒有接觸過資料庫,直接從指令開始會比較吃力。建議先學一點 SQL 語法,或從圖形介面工具開始操作,理解「表格、欄位、查詢」這些基本概念之後,再回來用指令會順很多。
07我只是做一個簡單的小專案,用這套會不會太重?
官方說明指出,它適合從小型應用到大規模企業系統。但如果你只是要存少量資料、不想管伺服器設定,官方文件也提到 SQLite 這類「免伺服器」的資料庫,特色是簡單、可攜、零設定。如果你的專案不需要多人同時連線、不需要複雜查詢,SQLite 可能更省事。
08這套軟體是免費的嗎?有沒有什麼限制?
它分為 Community Edition(免費、開放原始碼)和 Enterprise Edition(付費訂閱)。免費版功能已經很完整,但官方文件提到,進階功能像是即時分析、企業級技術支援,只有在付費的 Enterprise Edition 才有。如果你需要的是基本儲存和查詢,免費版通常夠用。
09我習慣用圖形介面,這套軟體有中文介面嗎?
它的介面語言是英文,而且主要操作介面是命令列。官方文件提到的第三方工具,像是 phpMyAdmin、MySQL Workbench,是否有中文介面需要另外確認。如果你很依賴中文介面,可能要考慮其他有提供在地化語言的資料庫工具,或先試用看看英文介面能不能接受。
10這套軟體在 Windows 上跑得順嗎?
官方說明指出,它支援 Windows、macOS 和 Linux,安裝過程通常是執行安裝程式、按幾個下一步。但官方文件也提醒,系統需求會依作業系統和版本而異,需要足夠的磁碟空間、記憶體和處理器效能。如果你的電腦規格比較舊,建議先確認官方列出的需求再安裝。
11我聽說 MySQL 很容易被駭,是真的嗎?
官方文件強調它提供多種驗證機制和加密選項來保護資料,但安全性很大程度取決於你怎麼設定。預設安裝完成後,如果你沒有修改預設帳號密碼、沒有設定防火牆規則,確實會有風險。建議安裝後第一件事就是設定強密碼、建立專用帳號,並關閉不需要的網路連線。
12這套軟體和 SQL Server Express 比起來,哪個比較適合我?
兩者都是免費的資料庫,但取向不同。SQL Server Express 是微軟的產品,和 Windows 環境、微軟開發工具整合較好;MySQL 則強調跨平台、支援多種程式語言。官方文件也提到,SQL Server 是 MySQL 的替代方案之一。如果你主要用微軟生態系,SQL Server Express 可能比較順;如果你需要跨平台或搭配開源技術,MySQL 會是常見選擇。
下載與官方連結
mysql-5.6.22-win32.msi · 44.73 MB · 連結指向軟體原廠
版本紀錄
- 2026-08-04 MySQL 8.0.46.0 566 MB
- 2026-01-20 MySQL 8.0.45.0 556 MB
- 2025-10-22 MySQL 8.0.44.0 558 MB
再看 5 筆
- 2025-07-23 MySQL 8.0.43.0 354 MB
- 2025-07-22 MySQL 8.0.42.0 354 MB
- 2025-01-21 MySQL 8.0.41.0 352 MB
- 2024-10-16 MySQL 8.0.40.0 306 MB
- 2024-07-29 MySQL 8.0.39.0 285 MB
這一版改了什麼
What's new in this version:
Compilation Notes:
- Noisy compiler warnings on FreeBSD 10 were silenced.
- CMake workarounds for older Mac OS X and XCode versions were removed. On Mac OS X, compilation always uses Clang, even for 32-bit builds.
- Compilation on Mac OS X is now supported for Mac OS 10.8 and up, using XCode 5 and up. Compilation on older versions may work but is unsupported.
- Previously, the MYSQL_MAINTAINER_MODE CMake option was turned on by default for debug builds and off for release builds, and MYSQL_MAINTAINER_MODE caused -Werror to be enabled when building with GCC. This made it cumbersome to enable -Werror under certain conditions, such as when compiling with Clang.
- Now, MYSQL_MAINTAINER_MODE is on by default when compiling debug builds with GCC, and MYSQL_MAINTAINER_MODE enbles -Werror regardless of whether GCC or Clang is used. Enabling -Werror with Clang can be done simply by explicitly setting -DMYSQL_MAINTAINER_MODE=1 when running CMake. In addition, some compilation warnings reported by Clang 3.4 were fixed, making it possible to build the default debug build with -Werror.
- Build support was modified to produce the same warnings for Clang as for gcc.
- CMake configuration for the Clang compiler sets more appropriate flags for building on Linux. Specifically, -g -fno-omit-frame-pointer -fno-strict-aliasing is now added. Security Notes:
- The linked OpenSSL library for the MySQL Commercial Server has been updated from version 1.0.1h to version 1.0.1j.
- This change does not affect the Oracle-produced MySQL Community build of MySQL Server, which uses the yaSSL library instead. Functionality Added or Changed:
- Replication: The variable binlogging_impossible_mode has been renamed binlog_error_action. binlogging_impossible_mode is now deprecated.
- The new -DWITH_UBSAN=ON CMake option enables the Undefined Behavior Sanitizer. This feature is supported by GCC 4.9 and up, and Clang 3.4 and up. Bugs Fixed:
- InnoDB: An ALTER TABLE operation raised an assertion. When a foreign key object was removed from the dictionary cache, an incorrect foreign key object was removed from the rb-tree.
- InnoDB: In debug builds, setting the innodb_limit_optimistic_insert_debug debug configuration option to 1 caused an infinite B-tree page split.
- InnoDB: The dict_set_corrupted() function attempted to update the clustered index of the SYS_INDEXES data dictionary table incorrectly.
- InnoDB: Pages with a checksum value of zero were incorrectly treated as empty pages. A page should only be considered empty if its checksum value and LSN field values are zero.
- InnoDB: The InnoDB data dictionary was not updated when a ALTER TABLE ... CHANGE COLUMN operation changed the case of the column name.
- InnoDB: A memory access violation caused fts_optimize_thread and mysqld to terminate. (Bug #19314480)
- InnoDB: A procedure, called from a function to perform an operation on a temporary table, caused the server to halt.
- InnoDB: Attempting to shut down the server after starting the server with innodb_force_recovery=6 resulted in a hang.
- InnoDB: A COMMIT operation related to full-text search resulted in a segmentation fault. (Bug #18503734)
- InnoDB: If a database is named using uppercase letters on a MySQL server with lower_case_table_names=2 (which is default on Mac OS X), InnoDB stores the database name as specified in the InnoDB internal system table (SYS_TABLES) but stores the name in lowercase on disk. During crash recovery, the case mismatch resulted in a conflict that would mark the tablespace .ibd file as missing. The patch for this bug converts database names to lowercase on crash recovery.
- InnoDB: In debug builds, the InnoDB Lock Monitor asserted after a DROP TABLE operation, and the InnoDB Monitor encountered an assertion in buf_page_get_gen. (Bug #18062698, Bug #71343, Bug #18173184, Bug #68116)
- InnoDB: A CREATE TABLE operation that failed with innodb_strict_mode=ON would succeed without printing a warning with innodb_strict_mode=OFF. (Bug #17852083)
- InnoDB: For explicit cache coherency, a write barrier was added to the head of os_thread_create_func(), and a read barrier was added to before the assertion code in rw_lock_free_func(). (Bug #13364876, Bug #62692, Bug #18870970, Bug #72809)
- InnoDB: The MySQL 5.6.20 patch for Bug #16963396 / MySQL Bug #69477 limited the size of redo log BLOB writes to 10% of the redo log file size. This limitation has been relaxed. Redo log BLOB writes are now limited to 10% of the total redo log size (innodb_log_file_size - innodb_log_files_in_group). As a result, innodb_log_file_size - innodb_log_files_in_group should be 10 times larger than the largest BLOB data size found in the rows of your tables plus the length of other variable length fields (VARCHAR, VARBINARY, and TEXT type fields). No action is required if innodb_log_file_size - innodb_log_files_in_group is already sufficiently large or if your tables contain no BLOB data. (Bug #73707, Bug #19498877)
- Partitioning: When multiple columns are used in KEY partitioning, their order may help determine the partition in which the row is placed. Changing this order by means of an ALTER TABLE that uses ALGORITHM=INPLACE can lead to inconsistency when placing rows in partitions; in other words, a row inserted before such an operation operation is placed in one partition, but the same row inserted afterwards is placed in a different one. For this reason, altering the order of a multicolumn index online is no longer allowed when that index is also used as the base for partitioning the table by KEY; instead, you must use a copying ALTER TABLE to perform the change.
- Replication: When using a MySQL version that had been compiled with the WITH_DEBUG option enabled, using expire_logs_days to purge binary logs caused a restart to crash the server. This problem arose after the fix for Bug #17283409. The fix ensures that current_thd is checked before calling DEBUG_SYNC().
- Replication: Sometimes the slave I/O thread leaves a partial group in the current relay log, for example when it is killed or stopped. After it is restarted, a new relay log is created on rotation and a pair of ROTATE_EVENT and FORMAT_DESCRIPTION_EVENT is replicated from master and written into the new relay log. When using a multi-threaded slave, problems such as error 1755 were encountered when applying the remaining part of the group in the relay log. This fix ensures that if MASTER_AUTO_POSITION is enabled, then the worker rolls back the partial group, finishes its work, and then applies the new complete copy of the group. If MASTER_AUTO_POSITION is disabled, the worker does not roll back the partial group.
- Replication: When using row-based replication with slave_type_conversions enabled, a binary log with more than one Rows_log_event in succession caused a crash. This was due to the temporary tables generated as part of the slave_type_conversions process being released too early. This fix ensures that the temporary tables are not released too early, and also ensures that long transactions do not cause an out of memory error.
- Replication: When using binary log files that had been manually copied from the master, for example to avoid I/O thread reading delay, the multi-threaded slave generated error 1755. Because the Previous_gtid_log_event is logged using the master's server_id and not the slave's server_id, the previous events were not being skipped correctly. This fix ensures that the events in Previous_gtid_log_event are always skipped, regardless of whether they are from the relay log (generated on the slave) or from the binary log (generated on the master and manually copied to the slave as the relay log).
- Replication: When replicating from an earlier version MySQL master, such as version 4.1, checksums are not used for events. Replicating to a slave running a newer version of MySQL, such as version 5.6, which has slave_sql_verify_checksum enabled by default meant that the last 4 bytes of events from the older master were being incorrectly interpreted as the checksum. A warning is now generated and to avoid such a situation, set slave_sql_verify_checksum=0 to disable checksums on the slave.
- Replication: When restarting MySQL with relay_log_recovery enabled to recover from a crash, if the SQL thread had never been started, the position from which to start recovery was not correctly initialized because Relay_Master_Log_File was missing. This fix ensures that in such a situation each of the relay logs, starting from the first relay log file, is searched for a rotate event from the master, which specifies where replication started from. This rotate event is then used to set the SQL thread's Relay_Master_Log_File and Relay_Log_Pos and recovery continues as normal.
- Replication: When using GTIDs for replication and with MASTER_AUTO_POSITION enabled, if a slave requested GTIDs which had been already been purged by the master, the master was sending all available GTIDs. This happened because the master reads all available binary logs and searches for a binary log which contains a GTID that is not contained in the union of gtid_executed and gtid_retrieved. If such a GTID is found, the master starts sending the information starting from that location. In a situation where the union of the slave's gtid_executed and gtid_retreived set did not contain the master's gtid_purged set, the slave would expect GTIDs which had already been purged by the master. This fix ensures that in such a situation, the slave's I/O thread is aborted with an error "Master has purged binary logs containing GTIDs that the slave requires.".
- Replication: A kernel mutex contention was being caused because mysqlbinlog was calling localtime() for every event read, which in turn called stat(/etc/localtime). This fix ensures that mysqlbinlog uses localtime_r(), which is optimized to store the read only timezone internal structure. This also means that mysqlbinlog now establishes the time zone at the beginning of processing and you can not change it during processing. This is the same behavior as MySQL server.
- Replication: The global scope for the sql_log_bin system variable has been deprecated, and this variable can now be set with session scope only. The statement SET GLOBAL SQL_LOG_BIN now produces an error. It remains possible for now to read the global value of sql_log_bin, but you should act to remove from your applications any dependencies on reading this value, as the ability to do so will be removed in a future MySQL release.
- InnoDB table checksum calculation could yield an incorrect result if the value of the innodb_checksum_algorithm system variable was modified during the operation.
- GROUP BY on a CHAR(0) NOT NULL column could lead to a server exit.
- With the validate_password plugin activated and dictionary lookups enabled, passing a user-defined variable to PASSWORD() could cause a server exit.
- Debian packages were built using the complex set of character sets, not the all set of character sets.
- mysqldump failed to report a disk-full error if the dump destination was located on an NFS mount.
- InnoDB permitted a foreign key to be created which referenced a parent table for which the user did not have sufficient privileges.
- Copying InnoDB tables containing full-text columns from Windows to Linux caused a server exit on Linux during full-text index initialization.
- On Windows, the replace utility did not work. (Bug #16581605)
- On CentOS 6, specifying a relative path name for the --socket option caused MySQL startup script failure.
- In Solaris 11.2, dtrace -V output changed from Sun D to Oracle D, causing detection of DTrace availability to fail during MySQL configuration.
- mysql_config --libs_r produces output containing link flags for libmysqlclient_r, even though that library was removed in MySQL 5.5 and replaced with a symlink to the underlying libmysqlclient library. The output now refers directly to libmysqlclient. (The implication is that it is no longer necessary to maintain the symlink for the sake of being able to use mysql_config --libs_r.)
- For statement digest calculation, the Performance Schema failed to recognize signed literal numbers as values representable by ? and created multiple digests for statements that should have had the same signature. Now all instances of unary plus and unary minus followed by a number reduce to ? in digests.
- Compilation on Windows using Visual Studio 2013 resulted in “unresolved external symbol” errors.
- OLD_PASSWORD() is deprecated, but no warning was produced when it was invoked.
- Certain queries for which subquery materialization or UNION DISTINCT was used together with a hash index on a temporary table could produce incorrect results or cause a server exit.
- The IS_FREE_LOCK() and IS_USED_LOCK() function implementations contained a race condition due to which they could access freed memory when a user lock was concurrently checked and freed. Accessing freed memory could result in an incorrect function return value or server exit.
- LOCK TABLES sometimes acquired an insufficiently strong lock for implicitly locked tables.
- The ENABLED_LOCAL_INFILE CMake option incorrectly was enabled by default.
- Use of ODBC-format date literals could produce incorrect query results.
- mysql_install_db ignored option files in the default locations.
- mysql_setpermission failed to properly quote user names in SQL statements that it generated.