問題場景 兩張表 info、tag，需根據 tag.name 在 info.name 中模糊匹配： info 表： tag 表： id |

為什麼需要 OPTIMIZE TABLE？ 大量刪除資料後，留下「空洞」（刪除記錄維持在鏈表中） 可變長度行（VARCHAR/BLOB/TEXT）頻繁更新導致

YEARWEEK 函數語法 YEARWEEK(date[, mode]) 回傳「年份 + 週數」的整數（如 201011 表示 2010 年第 11 週）。

測試環境準備 CREATE TABLE t1 ( a INT PRIMARY KEY AUTO_INCREMENT, b VARCHAR(10),

核心設計原則 1. 標準化與正規化（3NF） 第三範式（3NF）在效能、擴展性與資料完整性間取得最佳平衡： 一個事實在一個地方：表只包含自身基本屬性，非本質

為什麼使用儲存過程？ 效能提升：預編譯，減少網路傳輸（只傳呼叫命令） 維護性強：業務邏輯集中在資料庫端，不散落在應用程式碼中 安全性高：可控制存取權限，防止

資料庫/資料表操作錯誤 (1005-1011) 1005：建立表失敗 1006：建立資料庫失敗 1007：資料庫已存在 1008：資料庫不存在 1009：無法

冷備份優缺點速覽 優點缺點 極快（單純複製檔案）僅能恢復到備份時間點 歸檔簡單備份期間資料庫必須關閉 恢復容易（複製回去即可）磁帶備份速度慢 可結合歸檔

什麼是事務？ 事務是資料庫管理系統（DBMS）的執行單位，由一組有限的資料庫操作序列組成。必須滿足 ACID 四大特性： 特性英文說明 原子性Atomi

方法一：SET PASSWORD 命令（需登入後執行） SET PASSWORD FOR root@localhost = PASSWORD(newpass)

四級帳號體系設計 安裝 MySQL 後，建議建立四個不同權限的帳號，實現最小權限原則： 帳號用途權限範圍適用場景 root 超級管理員 所有資料庫、

為什麼欄位類型選擇至關重要？ 在建立資料表時，欄位類型的選擇直接影響儲存空間、查詢效能與資料完整性。雖然所有資料都能以字串形式儲存，但這樣做會導致： 儲存空間

前言 本文記錄在 Ubuntu 12.04 系統上，使用 GCC 4.6.3 編譯環境，從源碼編譯安裝 MySQL 5.5.28 的完整流程。由於 MySQL

MySQL 日期時間函數大全：40+ 函數分類速查 覆蓋日期提取、運算、格式化、轉換、時間戳互轉，附調用示例與輸出，適合開發調試快速查閱。 1. 日期部件提取

MySQL 結構對比技巧：導出格式決定 Diff 效率 需對比兩庫 Schema 差異時，導出格式關鍵： CLI mysqldump 默認單行插入多行 VAL

MySQL 5.6 Partition Exchange 實測：分區表與普通表秒級互換 MySQL 5.6 引入 ALTER TABLE ... EXCHANG

MySQL JOIN 圖解：INNER / LEFT / RIGHT JOIN 核心區別與實戰驗證 以「用戶表 user」與「密碼表 pwd」為例，通過建表、插

MySQL 日期時間格式化符號完整速查表 DATE_FORMAT(date, format)、TIME_FORMAT(time, format) 使用的格式佔位

MySQL 純 SQL 實現隨機密碼生成函數 無需應用層代碼，資料庫內即可生成指定長度、可自定義字符集的隨機字符串，適用於初始化密碼、生成 Token、測試數據

UPDATE TEXT 字段報 Row size too large 根因與修復 現象：更新一個 TEXT 列報錯 8126)，明明列是 TEXT（應溢出存儲