MySQL8.0の空間検索が遅い？の続き1

はじめに

昨日「MySQL8.0の空間検索が遅い？」という記事(以降「前記事」とする)を書いたのですが、それに対するバグ報告を見つけたので検証してみました。
残念ながら本記事でも原因は特定できておらず解決には至っていませんが、本不具合をMySQL開発チームが確認済みであることは確認できました。(ステータスがVerifiedとなっているため)

対象となるバグ報告

私が確認した事象に関すると思われる不具合報告は下記です。

Bug #94655 Some GIS function do not use spatial index anymore
Submitted: 14 Mar 11:04
https://bugs.mysql.com/bug.php?id=94655

同不具合報告では、MBRWITHIN関数は速いのに、MBRINTERSECTS関数やMBROVERLAPS関数は遅い、という結果になったことが報告されています。

報告者であるCedric Tabin氏が使用しているのはMBRINTERSECTSやMBRWITHINなどの関数ですが、私が検証した限りではST_IntersectsやST_WithIn関数でも同様の結果となるようです。

2019.9.8追記

新しく下記の不具合報告が上がっています。

Bug #96311 ST_Intersects() is very slow on MySQL 8.0
Submitted: 24 Jul 9:02
https://bugs.mysql.com/bug.php?id=96311

また、下記不具合報告も関連します。

Bug #96269 st_intersects mysql 8 does not use index
Submitted: 22 Jul 13:10
https://bugs.mysql.com/bug.php?id=96269

検証結果

前記事により、ST_Intersects関数を使った実行結果の件数は391件で、実行時間は1〜2分であることは確認できています。

よって今回はST_WithIn関数とST_Overlaps関数で検証してみました。

結果としてはCedric Tabin氏の検証結果同様に、ST_WithIn関数では実行速度は速い(1秒かからない)にも関わらず、ST_Overlapsは遅い(1〜2分)となることがわかりました。

ST_WithIn関数を使った検証SQLは下記です。

SELECT
  ST_AsGeoJson((SHAPE))
FROM
  `e_stat.utf8` 
WHERE 
  ST_WithIn(
    SHAPE,
    ST_GeomFromText(
      'POLYGON((43.08256990265745 141.3162472988521,                                                                                                                                                                                     
                43.056831004971265 141.3162472988521,                                                                                                                                               
                43.056831004971265 141.35259659542191,                                                                                                                                               
                43.08256990265745 141.35259659542191,                                                                                                                                                
                43.08256990265745 141.3162472988521))',
      4326
    )
 );

実行結果は下記でした。

297 rows in set (0.13 sec)

また、ST_Opverlaps関数を使った検証用のSQLは下記です。

SELECT
  ST_AsGeoJson((SHAPE))
FROM
  `e_stat.utf8` 
WHERE 
  ST_Overlaps(
    SHAPE,
    ST_GeomFromText(
      'POLYGON((43.08256990265745 141.3162472988521,                                                                                                                                                                                     
                43.056831004971265 141.3162472988521,                                                                                                                                               
                43.056831004971265 141.35259659542191,                                                                                                                                               
                43.08256990265745 141.35259659542191,                                                                                                                                                
                43.08256990265745 141.3162472988521))',
      4326
    )
 );

実行結果は下記でした。

94 rows in set (1 min 47.24 sec)

ちなみに、ST_Intersects、ST_WithIn、ST_Overlaps関数のそれぞれの意味は下記の記事がわかりやすかったです。

ST_Intersectsは、ST_WithInとST_OverlapsのORである気がするので(実際両関数の件数を足しあげるとST_Intersectsの件数と一致する)、せめてST_Overlapsが速ければ良かったのですが。

最後に

本不具合は2019年3月に登録され、最終更新が5月と比較的最近登録された不具合です。
Cedric Tabin氏の度重なる報告により、すでにMySQL開発チームの内部データベースに登録されているようですが、重要度はFeature Requestとあまり高くないように見えます。

ので、「Affects me」ボタンを押しておきました。

引き続き調査を続けたいと思います。