再帰的なストアドプロシージャの問題のMySQL

今日、同僚が欠落を示すツリー構造のデータは、プロジェクトが、このデータは、今日それが欠落しているどのように長い間何の問題のために実行すると述べ、問題はフロントエンドであることを考えるようになった、と後で右側のデバッグ・データ・ソースがオンになっていない見つけました。これは、次のように再帰クエリのMySQLのストアドプロシージャのコードは次のとおりです。

CREATE DEFINER = `@` root` ％ ` FUNCTION ` payment_database`.`getBusinessChildren`は（businessId BIGINT）RETURNS  VARCHAR（4000 ）CHARSETのutf8mb4を
    DETERMINISTIC
BEGIN 
DECLARE oTemp VARCHAR（4000 ）。
DECLARE oTempChild VARCHAR（4000 ）。
SET oTemp =  ' $ ' ;
SET oTempChild =  CAST（businessId AS  CHAR ）;
WHILE oTempChildはIS  NOT  NULL
行う 
SET oTemp = CONCAT（oTemp、' ' 、oTempChild）。
SELECT GROUP_CONCAT（business_id）INTO oTempChild FROM business_list WHERE FIND_IN_SET（PARENT_ID、oTempChild）> 0 。
ENDのWHILE ;
RETURN oTemp;
終わり

データベースは、データの80の以上の部分を有しているが、どのようにすべての76をチェックするストアドプロシージャを実行します。

8000かどうかにVARCHAR（4000）にしてみてください。

私たちのIDが、問題は、IDデータの第77条を改正発生し、77最初の変更の結果は、76チェックアウトではない比較的大きな疑わしいですので。この「容量」は小さすぎるようです。

オンライン検索ビット元のMySQLは、の文字列連結持つ GROUP_CONCAT関数 されているデフォルト値 = 1024 group_concat_max_lenを。

に変更されました

CREATE DEFINER = `@` root` ％ ` FUNCTION ` payment_database`.`getBusinessChildren`は（businessId BIGINT）RETURNS  VARCHAR（8000 ）CHARSETのutf8mb4を
    DETERMINISTIC
BEGIN 
DECLARE oTemp VARCHAR（8000 ）;
DECLARE oTempChild VARCHAR（8000 ）;
SET oTemp =  ' $ ' ;
SET oTempChild =  CAST（businessId AS  CHAR ）;
WHILE oTempChildはIS  NOT  NULL
行う
SET group_concat_max_len = 10240 ;
SET oTemp = CONCAT（oTemp、' ' 、oTempChild）。
SELECT GROUP_CONCAT（business_id）INTO oTempChild FROM business_list WHERE FIND_IN_SET（PARENT_ID、oTempChild）> 0 。
ENDのWHILE ;
RETURN oTemp;
終わり

問題を解決します！！

概要：実際には、このパフォーマンスは良くありません、それはMySQLでは再帰関数を書く、またはプログラムでそれを書くことは推奨されません。

再帰的なストアドプロシージャの問題のMySQL

おすすめ