活字格效能最佳化技巧（1）——如何利用資料庫主鍵提升訪問效能

葡萄城技術團隊發表於2023-04-06

本文由葡萄城技術團隊於部落格園原創並首發
轉載請註明出處：葡萄城官網，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。

大家都知道，活字格作為企業級低程式碼開發平臺，擁有6大引擎，3大能力，能夠高效落地企業級應用。在每年的應用大賽中也能看到很多格友利用活字格做了很多複雜的應用，例如2021年企業級低程式碼應用大賽中寧波聚軒利用活字格做的“軸管通”，整合了ERP、MES、WMS和裝置機聯網系統，為軸承行業開發出一套專業化、視覺化、數字化、物聯化、精細化的軸承管理平臺，既大氣，又實用。但最近有格友反饋，為什麼利用活字格開發出來的應用，頁面訪問的速度特別慢，是不是低程式碼開發平臺開發出來的應用效能就這麼“低效”呢？

先來跟大家分享一個例子，看看你是不是也有類似的困擾。

有一位格友利用活字格開發了一套應用系統，在系統中使用的資料庫是sqlserver。資料庫內主要儲存了司機的位置，資料量約有800多萬行。由於業務訪問需要，希望把這個表中的一些資料展示在使用活字格的開發的頁面中。考慮到資料量比較大，在頁面端採用分頁的方式會提升使用者訪問的效能，最佳化訪問體驗。看起來這個方案非常的完美，可是實際上的效果卻不盡人意。當開啟使用活字格做出來的頁面時，開啟的時間足足花費了2分鐘。真是不可思議，為什麼會這樣呢？

為了快速定位問題，葡萄城的工程師特意遠端連線到應用現場，看看如何解決客戶的困擾。工程師發現格友開發的應用確實是使用活字格開發，在訪問策略上也確實使用了分頁，那怎麼還是這麼慢呢？為了更深入的瞭解問題，特意對資料庫進行調查。

透過使用資料庫訪問語句：

SELECT COUNT(column_name) FROM table_name

發現在800萬+資料量的資料庫中知行上述語句花費的時間大約為2分鐘。

備註：在執行資料庫指令時並沒有使用活字格，而是直接在資料庫中執行。

到底是因為什麼原因導致應用訪問效率這麼低？在解開謎底之前，先給大家說明幾個簡單的概念。資料庫的主鍵、外來鍵和資料庫索引。

資料庫主鍵：指的是一個列或多列的組合，其值能唯一地標識表中的每一行，透過它可以強制表的實體完整性。主鍵主要是用與其他表的外來鍵關聯，以及本記錄的修改與刪除。除了能夠保證實體的完整性，主鍵還能加速資料庫的操作速度。

資料庫外來鍵：外來鍵是用於建立和加強兩個表資料之間連結的一列或多列。透過將儲存表中主鍵值的一列或多列新增到另一個表中，可建立兩個表之間的連結。這個列就成為第二個表的外來鍵。

資料庫索引：在關聯式資料庫中，索引是一種單獨的、物理的對資料庫表中一列或多列的值進行排序的一種儲存結構，它是某個表中一列或若干列值得集合和相應的指向表中物理標識這些值得資料頁的邏輯指標清單。索引的作用相當於圖書的目錄，可以根據目錄中的頁面快速找到所需的內容。索引可以有效提高查詢排序的速度。

再來舉個通俗的例如方便大家理解：我們可以把資料庫比做一個小區，每個人就是具體的“資料”，每個家就是一張表。為了方便找到人，通常會為每個家一個唯一的門牌號。我們可以認為這就是主鍵。那什麼是外來鍵呢？當你想和其他房間的人建立關聯關係時，會找一個雙方都認可的人，作為聯絡人，這個人就是外來鍵。而索引就是別人為了開始找到你，會先去問下小區的保安，他那邊會有一個全小區的住戶和房子的聯絡表，這樣你就不用一家家的去敲門了。（以上例子參考“程式設計師阿常”的分享）

看了上面的分享，大家可能已經猜到問題的解法了。沒錯，葡萄城的工程師嘗試給這個表設定主鍵,如下圖所示：

ALTER TABLE Persons
ADD PRIMARY KEY (ID);

資料庫執行了10分鐘，設定主鍵完畢。採用剛才的方法又重新測試了一下，使用相同的查詢語句，執行結果為“秒開”。重新在活字格中連線該資料庫，開啟頁面的時間只需要1秒鐘。
看到這裡大家已經掌握了提升訪問效能的一個非常重要的方法：主鍵。在實際使用的過程中大家要主要：資料庫的每張表只能有一個主鍵，不可能有多個主鍵；主鍵的主要作用是保證資料的唯一性和完整性，同時透過主鍵檢索表能夠增加檢索速度。

我們來一起看看如何在活字格中使用主鍵。如果您使用的是活字格內建的資料庫，那這個問題不用擔心。活字格內建的資料庫自帶主鍵，就是圖中畫了一個小鑰匙的這一列。