開發(fā)者必讀
此部分對于 ORM 的學習和使用非常重要。遇到使用問題時，請先確保自己認真看完了 ORM 組件的所有使用文檔，在對問題進行排查后，實在不能解決時再進行提問和反饋。
設計思想
ORM 全稱：object relational mapping，目的是想像操作對象一樣去操作數(shù)據(jù)庫，是符合面向對象開發(fā)思想的。
如將一條數(shù)據(jù)的插入，映射成一個對象的實例化。偽代碼如下所示：
<?php
$user = new UserModel();
$user->setData([
'attr' => 'value'
]);
$user->insert();常見問題匯總
重復使用 Model 對象
一個對象映射一條數(shù)據(jù)，此時會有很多用習慣了 db 封裝組件的小伙伴把 Model 當成了 db 封裝使用，重復調用一個 Model 對象，如下所示：
<?php
// 錯誤使用
// 假設id自增
$user = new UserModel();
// 插入一條新用戶
$user->setData([
'attr' => 'value'
]);
$user->insert();
// 插入第二條新用戶，此時由于重復調用同一個對象，產(chǎn)生報錯，自增 id 主鍵重復
$user->setData([
'attr' => 'value2'
]);
$user->insert();
ORM 生成復雜 sql
-
ORM是基于mysqli 3.x組件實現(xiàn)，內部引用mysqli組件中的QueryBuilder 類完成sql的構造，并且在QueryLimit章節(jié) 注明了閉包函數(shù)使用方式（可直接使用mysqli組件中的絕大部分連貫操作，如having等特殊條件） -
如果
mysqli組件的連貫操作也無法滿足您的需求，您有以下幾種方式解決該問題：- 使用自定義
sql執(zhí)行 - 嘗試給組件貢獻代碼，新增功能特性
- 提出反饋，我們會在精力允許和大眾所需時，對組件進行維護升級
- 使用自定義
優(yōu)雅刪除數(shù)據(jù)
在 ORM 設計思想中，對數(shù)據(jù)的操作映射為對對象的操作，如果按照此原則，那么需要我們先查詢出對象，然后再調用對象的 delete() 方法進行刪除。
但是對于執(zhí)行效率的消耗來說，此次查詢在部分業(yè)務場景下是無用的。
那么我們到底是否需要遵守設計原則？一般情況下是在 操作前需要校驗數(shù)據(jù)是否存在 時遵守，無需校驗則直接根據(jù)刪除條件傳參刪除即可。
設計原則代表思想，在某些場景下遵守它需要付出一定代價，開發(fā)者可以根據(jù)喜好去決定是否遵守。
刪除數(shù)據(jù)偽代碼如下所示：
<?php
$user = (new UserModel())->get($param['id']);
if (!$user){
return '操作數(shù)據(jù)不存在，請檢查再試';
}
$res = $user->delete();連接預熱
為了避免連接空檔期突如其來的高并發(fā)，我們可以對數(shù)據(jù)庫連接預熱，也就是 Worker 進程啟動的時候，提前準備好數(shù)據(jù)庫連接。
具體使用可查看 連接預熱 章節(jié)
斷線問題
為什么會斷線？
在連接池模式下，一個連接創(chuàng)建后，并不會因為因為請求結束而斷開，就好比 php-fpm 下的 pconnect 特性一樣。而一個連接建立后，可能會因為太久沒有使用(執(zhí)行 sql )，而被 mysql 服務端主動斷開了連接，或者是因為鏈路問題，切斷了連接。而連接被切斷的時候。我們并不知道這件事。因此就導致了我們用了一個斷線的數(shù)據(jù)庫連接去執(zhí)行 sql，從而出現(xiàn)斷線錯誤或者異常。
如何解決短線問題？
與 java 全家桶的原理一致，我們需要做的事情就是：
- 定時檢查連接是否可用
- 定時檢查連接的最后一次使用狀態(tài)
因此在 EasySwoole 的 ORM 中，ORM 組件提供了 IntervalCheckTime 配置項，它指定的就是多久做一次周期檢查，MaxIdleTime 配置項指的是如果一個連接超過這個時間沒有使用，則會被回收。AutoPing 配置項指的是多久執(zhí)行一個 select 1 用來觸發(fā)這個連接，讓這個連接被 mysql 服務端標記為活躍而不會被回收。如果經(jīng)常出現(xiàn)斷線，可以適當縮短 周期性檢查 和 AutoPing 的時間（即調整 IntervalCheckTime、AutoPing 配置項的值）。
百分百不會斷線了？
理論上，做了上面的步驟，出現(xiàn)使用斷線連接的概率是非常低的，但是并不是真的就百分百穩(wěn)了，比如極端情況：mysql 服務重啟，或者是鏈路斷線了。因此，我們一定要做類似如下這樣的處理措施：
<?php
try {
$client = $pool->getClient();
$cilient->query(xxxxxx);
} catch (\Throwable $t) {}也就是說，任何 orm 的使用，一定要 try。至于為何，請參考 java 為何強制對任何數(shù)據(jù)庫 io 做 try 處理。
為何不能做自動重連
我們可以看到，在某些自以為很聰明的框架中，有下面這樣的操作：
<?php
$client = $pool->getClient();
try {
return $client->query();
} catch(\Throwable $t) {
// 2006 2002 為斷線
if ($client->getError() == '2006') {
$client->connect();
return $client->query();
} else {
throw $t;
}
}乍一看，沒有什么問題。實際上，按照上面的重連，我們來看看下面的偽代碼：
<?php
$client = $pool->getClient();
$client->startTransaction();
$client->query(query one);
// client disconnect case network
$client->reconnect();
$client->query(query two);
$client->commit();這樣，在極端情況下，會導致 query one 結果丟失，但是 query two 卻執(zhí)行了，這對于事務來說，是不可原諒的。此刻又會有人說，那我判斷下鏈接是不是在事務中不就好了。實際上，遠遠沒這么簡單。為此，最好的方式就是我們養(yǎng)成良好的習慣。任何的數(shù)據(jù)庫 io，都做 try 操作，與 java 一致。