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

裝了 MySQL 之後不知道怎麼開始?它能做什麼、該不該用

MySQL (32-bit) 軟體圖示 MySQL (32-bit) 5.1.46 資料更新 2010-04-23 閱讀約 6 分鐘

你剛把 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 (32-bit)

mysql-essential-5.1.46-win32.msi · 39.08 MB · 連結指向軟體原廠

版本紀錄

再看 5 筆

看完整版本清單

這一版改了什麼

What's new in this version:

#InnoDB Plugin Notes:

* InnoDB Plugin has been upgraded to version 1.0.7. This version is considered of General Availability (GA) quality. The InnoDB Plugin Change History may contain information in addition to those changes reported here.

* In this release, the InnoDB Plugin is included in source and binary distributions, except RHEL3, RHEL4, SuSE 9 (x86, x86_64, ia64), and generic Linux RPM packages. It also does not work for FreeBSD 6 and HP-UX or for Linux on generic ia64.

#Functionality added or changed:

* There is a new system variable, skip_name_resolve, that is set from the value of the --skip-name-resolve server option. This provides a way to determine at runtime whether the server uses name resolution for client connections. (Bug#37168)

# Bugs fixed:

* Security Fix: Privilege checking for UNINSTALL PLUGIN was incorrect. (Bug#51770)
* Partitioning: Partition pruning on RANGE partitioned tables did not always work correctly; the last partition was not excluded if the range was beyond it (when not using MAXVALUE). Now the last partition is not included if the partitioning function value is not within the range. (Bug#51830)
* Partitioning: The insert_id server system variable was not reset following an insert that failed on a partitioned MyISAM table having an AUTO_INCREMENT column. (Bug#50392)
* Partitioning: Foreign keys are not supported on partitioned tables. However, it was possible via an ALTER TABLE statement to set a foreign key on a partitioned table; it was also possible to partition a table with a single foreign key. (Bug#50104)
* Partitioning: GROUP BY queries performed poorly for some partitioned tables. This was due to the block size not being set for partitioned tables, thus the keys per block was not correct, which could cause such queries to be optimized incorrectly. (Bug#48229) See also Bug#37252.
* Partitioning: REPAIR TABLE failed for partitioned ARCHIVE tables. (Bug#46565)
* Replication: TRUNCATE TABLE performed on a temporary table using the InnoDB storage engine was logged even when using row-based mode. (Bug#51251)
* Replication: When using temporary tables the binary log needs to insert a pseudo-thread ID for threads that are using temporary tables, each time a switch happens between two threads, both of which are using temporary tables. However, if a thread issued a failing statement before exit, its ID was not recorded in the binary log, and this in turn caused the ID for the next thread that tried to do something with a temporary table not to be logged as well. Subsequent replays of the binary log failed with the error Table ... doesn't exist. (Bug#51226)
* Replication: If the master was using sql_mode='TRADITIONAL', duplicate key errors were not sent to the slave, which received 0 rather than the expected error code. This caused replication to fail even when such an error was expected. (Bug#51055)
* Replication: When run with the --database option, mysqlbinlog printed ROLLBACK statements but did not print any corresponding SAVEPOINT statements. (Bug#50407)
* Replication: CREATE EVENT statements were padded with “garbage” characters when written to the binary log, which caused a syntax error when trying to read back from the log. (Bug#50095)
* Replication: Column length information generated by InnoDB did not match that generated by MyISAM, which caused invalid metadata to be written to the binary log when trying to replicate BIT columns. (Bug#49618)
* Replication: The value of Slave_IO_running in the output of SHOW SLAVE STATUS did not distinguish between all 3 possible states of the slave I/O thread (not running; running but not connected; connected). Now the value Connecting (rather than No) is shown when the slave I/O thread is running but the slave is not connected to a replication master. The server system variable Slave_running also reflects this change, and is now consistent with what is shown for Slave_IO_running. (Bug#30703, Bug#41613, Bug#51089)
* EXPLAIN EXTENDED crashed trying to resolve references to freed temporary table columns for GROUP_CONCAT() ORDER BY arguments. (Bug#52397)
* For InnoDB Plugin, bit fields were causing problems with concurrency on SMP systems because of word-packing issues. (Bug#52360)
* The optimizer could attempt to evaluate the WHERE clause before any rows had been read, resulting in a server crash. (Bug#52177)
* For LDML-defined collations, some data structures were not initialized properly to enable UPPER() and LOWER() to work correctly. (Bug#51976)
* On Windows, LOAD_FILE() could cause a crash for some pathnames. (Bug#51893)
* Invalid memory reads occurred for HANDLER ... READ NEXT after a failed HANDLER ... READ FIRST. (Bug#51877)
* After TRUNCATE TABLE of a MyISAM table, subsequent queries could crash the server if myisam_use_mmap was enabled. (Bug#51868)
* If myisam_sort_buffer_size was set to a small value, table repair for MyISAM tables with FULLTEXT indexes could crash the server. (Bug#51866)
* In LOAD DATA INFILE, using a SET clause to set a column equal to itself caused a server crash. (Bug#51850)
* A problem with equality propagation optimization for prepared statements and stored procedures caused a server crash upon re-execution of the prepared statement or stored procedure. (Bug#51650) See also Bug#8115, Bug#8849.
* The optimizer performed an incorrect join type when COALESCE() appeared within an IN() operation. (Bug#51598)
* The server crashed when the optimizer attempted to determine constant tables but a table storage engine did not support exact record count. (Bug#51494)
* The server could crash populating the INFORMATION_SCHEMA.PROCESSLIST table due to lack of mutex protection. (Bug#51377)
* Use of HANDLER statements with tables that had spatial indexes caused a server crash. (Bug#51357)
* With an XA transaction active, SET autocommit = 1 could cause side effects such as memory corruption or a server crash. (Bug#51342)
* Following a bulk insert into a MyISAM table, if MyISAM failed to build indexes using repair by sort, data file corruption could occur. (Bug#51307)
* CHECKSUM TABLE could compute the checksum for BIT columns incorrectly. (Bug#51304)
* A HAVING clause on a joined table in some cases failed to eliminate rows which should have been excluded from the result set. (Bug#51242)
* The type inference used for view columns caused some columns in views to be handled as the wrong type, as compared to the same columns in base tables. DATE columns in base tables were treated as TIME columns in views, and base table TIME columns as view DATETIME columns. (Bug#50918)
* The YEAR values 2000 and 0000 could be treated as equal. (Bug#49910)
* Performing a single in-place ALTER TABLE containing ADD INDEX and DROP INDEX options that used the same index name could result in a corrupt table definition file. Now such ALTER TABLE statements are no longer performed in place. (Bug#49838)
* mysql_upgrade did not detect when CSV log tables incorrectly contained columns that could be NULL. Now these columns are altered to be NOT NULL. (Bug#49823)
* If a stored function contained a RETURN statement with an ENUM value in the ucs2 character set, SHOW CREATE FUNCTION and SELECT DTD_IDENTIFIER FROM INFORMATION_SCHEMA.ROUTINES returned incorrect values. (Bug#48766)
* The server crashed when it could not determine the best execution plan for queries involving outer joins with nondeterministic ON clauses such as the ones containing the RAND() function, a user-defined function, or a NOT DETERMINISTIC stored function. (Bug#48483)
* A query that read from a derived table (of the form SELECT ... FROM (SELECT ...)) produced incorrect results when the following conditions were present:
- The table subquery contained a derived query ((SELECT ... ) AS column).
- The derived query could potentially produce zero rows or a single NULL (that is, no rows matched, or the query used an aggregate function such as SUM() running over zero rows).
- The table subquery joined at least two tables.
- The join condition involved an index. (Bug#47904)
* The optimization to read MIN() or MAX() values from an index did not properly handle comparisons with NULL values. This could produce incorrect results for MIN() or MAX()when the WHERE clause tested a NOT NULL column for NULL. (Bug#47762)
* Killing a query during the optimization phase of a subquery could cause a server crash. (Bug#47761)
* The query shown by EXPLAIN EXTENDED plus SHOW WARNINGS could produce results different from the original query. (Bug#47669)
* Renaming a column of an InnoDB table caused the server to go out of sync with the InnoDB data dictionary. (Bug#47621)
* MyISAM could write uninitialized data to new index pages. Now zeros are written to unused bytes in the pages. (Bug#47598)
* Setting myisam_repair_threads larger than 1 could result in the cardinality for all indexes of a MyISAM table being set to 1 after parallel index repair. (Bug#47444)
* In debug builds, if the listed columns in the view definition of the table used in an INSERT ... SELECT statement mismatched, an assertion was raised in the query cache invalidation code following the failing statement. (Bug#46615)
* For a query that selected from a view and used an alias for the view, the metadata used the alias name rather than the view name in the MYSQL_FIELD.table member. (Bug#41788)
* mysql_upgrade did not create temporary files properly. (Bug#41057)
* It was possible for DROP TABLE of one MyISAM table to remove the data and index files of a different MyISAM table. (Bug#40980)
* If the arguments to a CONCAT() call included a local routine variable, selecting the return value into a user variable could produce an incorrect result. (Bug#40625)
* SHOW CREATE VIEW returned invalid SQL if the definition contained a SELECT 'string' statement where the string was longer than the maximum length of a column name, due to the fact that this text was also used as an alias (in the AS clause). Because not all names retrieved from arbitrary SELECT statements can be used as view column names due to length and format restrictions, the server now checks the conformity of automatically generated column names and rewrites according to a predefined format any names that are not acceptable as view column names before storing the final view definition on disk. In such cases, the name is now rewritten as Name_exp_pos, where pos is the position of the column. To avoid this conversion scheme, define explicit, valid names for view columns using the column_list clause of the CREATE VIEW statement. As part of this fix, aliases are now generated only for top-level statements. (Bug#40277)
* While looking for the shortest index for a covering index scan, the optimizer ignored that a clustered primary key read the entire table. (Bug#39653)
* mysqlbinlog had a memory leak in its option-processing code. (Bug#38468)
* The test for readline during configuration failed when trying to build MySQL in a directory other than the source tree root. (Bug#35250)