Free
永久免費
US$0
一台伺服器，一切盡收眼底。
- 一個已儲存的連線。示範連線，以及從主要伺服器開啟的備援伺服器，不計入其中。
- 健康狀態、活動、鎖定、Purge 與膨脹、複寫、儲存空間與慢查詢
- 釘選指紋的 TLS、SSH 通道與 Face ID
- 資料瀏覽器：伺服器篩選、外來鍵、CSV 匯出與 JSON 拷貝
- 附分類器的唯讀 SQL
RowDeck: MySQL® Monitor iPhone 版
看清 MySQL 裡哪裡在著火。 把火撲滅。
半夜收到警報，筆電卻在家裡？RowDeck 一開啟就是「健康狀態」畫面，會找出持有鎖定的交易，並算出卡在它後面的工作階段數量。在 iPhone 上終止該終止的執行緒，回到電腦前再徹底修正。
即將在 App Store 上架 上架時寄信通知
支援 MySQL 8.0 及更新版本MariaDB 10.5 及更新版本Percona Server for MySQLAmazon RDSAurora MySQL自行架設的伺服器
- iPhone 與資料庫之間沒有 RowDeck 伺服器
- 密碼與金鑰留在這支 iPhone 的 Keychain 中
- 首次連線時釘選 TLS 憑證與 SSH 主機金鑰
- 所有監控畫面皆免費，沒有時間限制
凌晨 3 點的處理流程
從收到警報到解除阻擋，只需四個畫面。
內建示範會重現一次常見的 MySQL 事件：一個被遺忘的交易持有 shop.orders 的資料列鎖定，一次遷移在它後面等待，八個工作階段排起了隊。選擇一個步驟，查看對應的畫面。
不連伺服器也能試用：在「連線」畫面點一下查看示範資料。不需要帳號，Pro 操作會在範例資料上執行。
-
資料列鎖定
InnoDB 鎖定等待依持有鎖定的執行緒分組，並顯示每個等待者執行的 SQL 與已等待的時間。
-
Metadata locks
ALTER TABLE佇列：誰在等待資料表的 metadata lock、哪個交易一直佔著它，還有一個按鈕可以改為取消等待中的ALTER。 -
Deadlocks
InnoDB 記錄的最近一次 deadlock：誰在等待什麼，以及哪個交易被回復。
-
在 Amazon RDS 上終止
在 Amazon RDS 或 Aurora 上沒有
KILL權限？RowDeck 會呼叫mysql.rds_kill，並在確認面板中寫明走的是哪條途徑。
Purge 與膨脹 趕在 INSERT 開始失敗之前，盯住
趕在 INSERT 開始失敗之前，盯住 AUTO_INCREMENT。
「Purge 與膨脹」畫面顯示每個自動遞增範圍已經用掉多少、purge 落後了多少，以及哪些資料表與索引白白佔著空間。
- 依欄位顯示餘量。
order_items.id用到INT範圍的 93% 時，RowDeck 會警告範圍用盡後每個 INSERT 都會失敗，並拷貝用來加寬該欄位的ALTER。 - History list length，以及讓 InnoDB 無法 purge 舊資料列版本的最舊交易。
- 片段化的資料表，以及未使用或重複的索引與各自佔用的空間。
- 可直接在清單中執行
ANALYZE TABLE；輸入資料表名稱後可執行OPTIMIZE TABLE。DROP INDEX與ALTER陳述式會拷貝到剪貼簿，何時執行由自己決定。 PRO
App 裡有什麼
MySQL 事件發生時要打開的每一個畫面。
最前面是「健康狀態」畫面，每張卡片背後都有一個原生畫面，不必在手機鍵盤上輸入 mysql 命令列。其餘情況交給 SQL 主控台，每個陳述式執行前都會先經過檢查。
-
健康狀態
一個整體判斷加上十張附有門檻值的卡片：連線數對照
max_connections、被阻擋的執行緒、最久的查詢、每秒查詢數、Buffer pool 命中率、purge 延遲、AUTO_INCREMENT 餘量、Deadlocks、複寫與磁碟。畫面開啟期間每 10 秒重新整理一次，和 iOS 一樣提供深色與淺色外觀。 -
活動
processlist 中的每個執行緒，等待中的排在最前面。可依執行中、交易中、超過 10 秒或等待中篩選，也可以依用戶端分組。
-
複寫
在備援伺服器上：IO 與 SQL 執行緒、延遲，以及讓某個通道停止的錯誤。在主要伺服器上：已連線的備援伺服器，以及 binlog 佔用的空間。
-
慢查詢
來自
performance_schema的陳述式摘要，可依總時間、平均時間、呼叫次數或已檢查資料列數排序。 -
儲存空間
最大的架構、資料表與索引，分為資料、索引與可用空間。
-
資料
瀏覽資料表、在伺服器上篩選、沿著外來鍵跳轉，將一頁資料匯出為 CSV 或拷貝為 JSON。資料列編輯屬於 Pro。
-
SQL 主控台
輸入時，分類器就會為每個陳述式加上標籤：讀取、寫入、DDL 或破壞性。Free 執行讀取，Pro 執行其餘陳述式。
- PRO
在自有模型上運行的 AI 助理
說明事件或阻擋鏈，並草擬修正方式。它讀取遮蔽後的快照，送出前先顯示要傳送的內容，本身不執行任何操作。在示範中免費。
- Anthropic
- OpenAI
- OpenRouter
- Z.ai
- 相容 OpenAI 的伺服器
- 自有網路中的 Ollama
寫入之前
從指尖到伺服器，中間隔著四道檢查。
RowDeck 依序逐一檢查。任何一步沒通過，操作就會停止，不會有任何內容送達 MySQL。
- 1
Pro
Free 從不寫入伺服器。
- 2
Read-only 連線
將連線標記為 Read-only，該連線上的寫入就會停止，Pro 也不例外，直到為這次工作階段解鎖寫入為止。
- 3
分類器
會檢查每一個陳述式，Free 與 Pro 皆然。
- 4
使用者確認
預覽中顯示目標、架構、連線與 PROD 徽章。破壞性操作，以及 Production 連線上的終止操作，須先輸入目標才會執行。
SELECT * FROM orders WHERE id = 4820118; 讀取 UPDATE orders SET status = 'shipped' WHERE id = 4820118; 寫入 CREATE INDEX idx_orders_total ON orders (total); DDL TRUNCATE TABLE shop.sessions; 破壞性 -
經由堡壘主機
SSH 支援密碼、一次性驗證碼或金鑰：OpenSSH、PEM、PKCS#8 或 PuTTY 格式的 Ed25519、ECDSA 或 RSA 金鑰，或是 Secure Enclave 金鑰。堡壘主機後方最多還可再加兩台跳板主機。
-
釘選 TLS 憑證
首次連線時，RowDeck 會顯示伺服器憑證的 SHA-256 指紋；之後憑證一旦變更，連線就會停止。
-
Keychain 與 Face ID
密碼、金鑰與指紋儲存在這支 iPhone 的 iOS Keychain 中。以 Face ID 開啟 App。
-
沒有 PROCESS 也據實以告
沒有此權限時，MySQL 只會顯示目前帳號自己的執行緒。RowDeck 會直接說明，並提供解決方法：
GRANT PROCESS ON *.* TO 'oncall'@'%';
截圖
逐一畫面檢視 MySQL。
RowDeck 1.0，使用內建示範資料。
健康狀態 打開筆電之前就看清事件。
鎖定 資料列鎖定與 metadata lock 在同一個樹狀圖中。
終止連線 確認之前，先看會解除哪些阻擋。
活動 等待中的執行緒排在最前面。
索引 未使用與重複索引，DROP INDEX 已代為拷貝。
複寫 通道狀態與待套用的交易。
慢查詢 依總時間排序。
儲存空間 最大的資料表與索引。
資料 在本頁篩選或在伺服器上篩選。
SQL 主控台 每個陳述式都經過分類。
DDL 執行之前先看分類器的判斷。
助理 模型自己選，每個操作自己決定。
SSH 通道 使用自己的金鑰與跳板主機。
價格
監控免費。Pro 只需購買一次。
把 RowDeck 連上正式環境伺服器，所有監控畫面都免費使用。到了需要出手的那個夜晚，再一次支付 US$14.99。
Pro
一次性購買
US$14.99
在任何伺服器上出手。
- 不限數量的已儲存連線
- 終止查詢和連線，解除阻擋鏈
- 執行
ANALYZE TABLE與OPTIMIZE TABLE - 寫入、DDL 與資料列編輯，皆須確認
- 使用自己的金鑰或自己的 Ollama 的 AI 助理
不需訂閱，也不需帳號。購買之前，可以先在示範的範例資料上試用每一項 Pro 操作。「回復購買項目」位於付費畫面與「設定」中。在美國以外的地區，App Store 會以當地貨幣顯示價格。
即將在 App Store 上架 上架時寄信通知
支援 Amazon RDS、Aurora 或自行架設的伺服器嗎？
只要 iPhone 連得到，RowDeck 就能連線到 MySQL 8.0 及更新版本與 MariaDB 10.5 及更新版本，不論自行架設或代管，包括 Amazon RDS 與 Aurora MySQL。Percona Server for MySQL 也可以使用。
在 Amazon RDS 與 Aurora 上，管理員無法 KILL 其他使用者的執行緒，RowDeck 會改為呼叫供應商提供的預存程序 mysql.rds_kill。在代理伺服器後方時，RowDeck 不會送出 KILL，因為執行緒 ID 可能屬於另一台伺服器，而是提供須在伺服器本身執行的陳述式。
MySQL 5.7 與 10.5 之前的 MariaDB 不在支援範圍內，TiDB 的監控資料表也不一樣。連線時 App 會提示。
能連到堡壘主機後方的資料庫嗎？
可以。在連線設定中開啟 SSH 通道，以密碼、金鑰或在這支 iPhone 上產生的 Secure Enclave 金鑰登入堡壘主機。金鑰可以是 OpenSSH、PEM、PKCS#8 或 PuTTY 格式的 Ed25519、ECDSA 或 RSA 金鑰，有無金鑰密碼皆可。伺服器要求一次性驗證碼時，也可以使用。
如果堡壘主機位於另一台主機後方，最多可新增兩台跳板主機。RowDeck 會在首次連線時釘選每台主機的主機金鑰，其中任何一個變更，都會拒絕繼續。
登入資訊或資料會離開 iPhone 嗎？
RowDeck 直接連線到伺服器，或經由堡壘主機連線。中間沒有 RowDeck 伺服器，也不需要帳號。密碼與金鑰留在 iOS Keychain 中。
在首次啟動的畫面上點一下「完成」後，當機報告會傳送到 Sentry，使用統計會傳送到我們自己的分析伺服器；該畫面上的兩個開關預設皆為開啟。可以當場關閉其中任一項，也可以之後在「設定 › 隱私權」中關閉。兩者都不包含 SQL、架構名稱、資料表名稱、欄位名稱、主機名稱、值或登入資訊。詳情請見隱私權政策。
需要 SUPER 或管理員帳號嗎？
不需要。監控畫面只需要唯讀權限，連線表單中分別列出了 MySQL 與 MariaDB 所需的授權。最重要的是 PROCESS：沒有它，MySQL 只會顯示目前帳號自己的執行緒，RowDeck 會在每個畫面上說明這一點，而不是顯示空白清單。
Pro 操作要終止其他使用者的執行緒，需要 CONNECTION_ADMIN；在 Amazon RDS 與 Aurora 上，RowDeck 會改用供應商的終止預存程序。伺服器隱藏的指標會顯示原因，絕不顯示為零。
KILL QUERY 還是 KILL CONNECTION：該用哪個？
KILL QUERY 會停止執行中的陳述式，保留連線及其交易。KILL CONNECTION 會關閉連線，並回復其開啟的交易。
在開啟的交易中處於 Sleep 狀態的執行緒沒有執行中的陳述式，所以 KILL QUERY 對它沒有作用，鎖定也仍然保留。RowDeck 會讀取根源正在做什麼，並提供能釋放佇列的那種終止方式。
RowDeck 會把資料庫弄壞嗎？
Free 從不寫入：主控台的讀取會在唯讀交易內執行。在 Pro 中，每次寫入都要依序通過四道檢查：Pro、連線的 Read-only 開關、分類器，以及使用者的確認。破壞性陳述式須先輸入目標才會執行，標記為 Production 的連線會顯示 PROD 徽章，確認也更嚴格。
RowDeck 會代為拷貝 DROP INDEX 與 ALTER … BIGINT，是否執行由自己決定。它不會 purge binlog，也不會在備援伺服器上略過交易；它從不向伺服器要求 LOAD DATA LOCAL，也從不在一次呼叫中要求執行多個陳述式。
為什麼不直接 SSH 進去執行 mysql？
當然可以。但凌晨 3 點在手機鍵盤上，RowDeck 省去了跨 performance_schema 與 information_schema 的 JOIN 查詢：阻擋樹狀圖、等待中的 ALTER 以及它背後的交易，從「健康狀態」畫面點一下就能看到。
AI 助理看得到什麼？
所詢問畫面的遮蔽後快照。主機、連接埠、IP 位址、連線名稱與密碼絕不會送出，陳述式內的值也不會。使用雲端模型時，架構、資料表與欄位名稱會以 table_1 這類預留位置送出，RowDeck 再於 iPhone 上換回真實名稱。
請求會從 iPhone 送往所選的供應商，使用自己的金鑰（Anthropic、OpenAI、OpenRouter、Z.ai 或任何相容 OpenAI 的端點），或送往自己的 Ollama。送出之前可以看到模型將收到的內容。助理屬於 Pro，在示範中免費，不會自行執行 SQL。
需要訂閱嗎？
不需要。Pro 是一次性購買，價格 US$14.99，與 Apple 帳戶綁定。監控始終免費，沒有帳號，也沒有試用期倒數。
出問題時會發出警報嗎？
不會。RowDeck 不在背景運作，關閉後也不會監看伺服器。現有的警報系統照常使用：RowDeck 是收到警報後打開的那個畫面。
可以在 iPad 上使用嗎？
RowDeck 專為直向 iPhone 設計，沒有專屬的 iPad 版面配置。
Amazon Web Services、AWS、Amazon RDS 與 Amazon Aurora 是 Amazon.com, Inc. 或其關係企業的商標。RowDeck 與 Amazon 並無關聯，亦未獲其認可。
指南
MySQL 事件指南。
半夜把人叫醒的那些問題，每個一頁：手動執行的 SQL，以及 RowDeck 中的顯示。
指南與部落格為英文。
- Kill a stuck MySQL query from your iPhone KILL QUERY or KILL CONNECTION? Stop a stuck MySQL or MariaDB thread from your iPhone, idle transactions and mysql.rds_kill on Amazon RDS included.
- Find blocking queries in MySQL from your iPhone Find the thread behind ERROR 1205 Lock wait timeout exceeded with sys.innodb_lock_waits, data_lock_waits or INNODB_TRX, and see the lock tree on iPhone.
- Waiting for table metadata lock: fix a hung ALTER TABLE ALTER TABLE hangs on Waiting for table metadata lock and queries pile up behind it. Find the holder in metadata_locks and pick what to kill, from your iPhone.
- AUTO_INCREMENT overflow in MySQL and MariaDB Find AUTO_INCREMENT columns close to the INT limit before INSERTs fail with ERROR 1062 on 2147483647, and plan the move to BIGINT.
- InnoDB history list length and purge lag History list length climbing? Find the open transaction that blocks InnoDB purge on MySQL or MariaDB, and see purge lag and its holder on your iPhone.
- MySQL replication lag and a stopped replica Read SHOW REPLICA STATUS on MySQL and MariaDB, tell NULL lag from zero, see why the SQL thread stopped and how much disk the binlogs hold.
- SSH tunnel to MySQL from your iPhone Reach MySQL or MariaDB behind a bastion from your iPhone: an SSH key, authorized_keys, a host key check with ssh-keygen -lf, jump hosts and TLS.
- MySQL processlist on your iPhone Read the MySQL processlist on your iPhone: SHOW PROCESSLIST vs performance_schema.processlist, the PROCESS privilege, and Sleep threads that hold a transaction.
部落格文章
所有文章- ERROR 1040 Too many connections: getting back into a full MySQL server Once max_connections is full, MySQL turns away new clients, you included. The reserved admin slot, the admin port, and finding who holds the slots.
- Why KILL QUERY didn't release the row lock A MySQL thread asleep in an open transaction keeps its row locks, and KILL QUERY can't touch it. Finding that thread, ending it, and stopping the next one.
- One ALTER TABLE can stop every query on a MySQL table A migration waiting for a metadata lock queues each later query on its table. Finding the forgotten transaction behind it and keeping it from coming back.
