我有一個巨大的地理資料庫，我經常需要將其與實時地理資料進行比較，以確定每個緯度：經度的最近位置。位置表確實包含許多行，但很少添加新記錄。即使在實施了矩形距離比較演算法（而不是通過 Haversine 進行實際比較）之后，根據數百萬實時資料確定最近的位置也讓我們付出了超慢查詢的痛苦。
我想將此比較與 DETERMINISTIC 函式進行轉換，該函式應該真正通過靜態結果帶來真正的性能提升。
但是，我希望 MySQL 每周重置/重建這個確定性結果快取。就像，我希望 MySQL 為 Latitude:Longitude 對回傳與我的位置表比較的相同結果，但持續 7 天。7 天后，我很有可能會在該表中添加新位置，并且我希望 MySQL 開始重建確定性函式結果快取，考慮到該表中添加了新行，最好不重新啟動 MySQL 服務器。
注意：一個符合 MariaDB 的解決方案是一個非常好的解決方案 :)
更正：請原諒我在 MySQL 中使用該術語。到目前為止，我可以理解，對于所有輸入都相同的確定性函式，結果不會改變，這讓我認為 MySQL 實際上并不傾向于執行或處理函式內部的指令，而是回傳先前計算的值相同的輸入值集，因此，它肯定會在某處快取值（我不知道在哪里），因此表現得就像只是通過串列查找或類似的東西。我想我在這里用 CACHE 多載了 OPTIMIZER :(
uj5u.com熱心網友回復：
我認為您誤解了DETERMINISTIC作為選項的含義CREATE FUNCTION。
這并不意味著函式的結果被記憶。沒有函式結果的快取。沒有重繪 此快取的命令，因為沒有保留結果。
的含義DETERMINISTIC主要影響二進制日志：
https://mariadb.com/kb/en/create-function/#not-deterministic
該
[NOT] DETERMINISTIC子句還影響二進制日志記錄，因為該STATEMENT格式不能用于存盤或復制非確定性陳述句。
也就是說，如果在副本上執行非確定性函式，它可能會回傳不同的結果，因此如果您在修改資料的 SQL 陳述句中使用該函式，則該事件的二進制日志格式必須ROW確保應用相同的更改復制品上。
還有一個模糊的參考：
如果優化器知道函式是確定性的，它可能會選擇更快的執行計劃。
但沒有給出這種情況的例子。這可能是罕見的，因為它會產生顯著的性能差異。
我認為這不會是您的用例的有效性能優化。
uj5u.com熱心網友回復：
函式不是您可以獲得性能的地方。（比爾討論過。）演算法是你可以獲得性能的地方。（我會談到那個。）
簡單的選擇涉及檢查百萬行中的每一行的距離。正如您所發現的，這是不可擴展的。
接下來是INDEX(lat, lng), INDEX(lng, lat)使用邊界框。這給出了一個數量級的加速。
類似的改進來自使用SPATIAL值和索引。
我在Find Nearest中詳細介紹了這 3 種方法。該鏈接還提供了兩個速度更快的演算法，但您可能只需要幾百萬行就不需要那么多改進（和復雜性）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/442024.html
上一篇：Ruby-一行中的排列程式
下一篇：在R中創建隨機播放函式