2021 11,23 00:01 |
|
基本、定義書ぐらい残しておけよと思うけど
ちゃんとやらない奴も多いのでね。 対象のプラットフォームは、mac、またはlinux mysqldumpを使い、XML形式でテーブル定義を出力することができるので、 そのXMLを使って作成するということ。 1) mysqldump --no-data --xml -u root -p [ DB名 ] > [出力ファイル.xml] 2) MySQL テーブル仕様書メーカー から、XSLT スタイルシートを利用させて頂きます。 上記でコピーしたファイルものせておく 3) xsltproc -o [出力ファイル.xml] style.xsl [出力ファイル.html] あくまでも簡易的なもの 無いよりマシぐらいな扱いでしょうか。 参考:https://qiita.com/mamy1326/items/c0aa9252d61ffed31a6e PR |
|
2021 09,09 16:48 |
|
軽くはまった
昔にも、同じようなことがあったけど、起きた事象が異なったが、 原因は同じ group_concatの落とし穴 昔は、group_concatで結合したものが欠落して表示されるということ 今回は、条件に一致する複数レコードのカラムを1つのカラムとして結合 そのカラムの中身がJSONデータ そのJSONデータが欠落して、不完全なJSONとして扱われ、MySQLでエラー なので、そのクエリを実行する前に SET group_concat_max_len = 200000; として、上記のSQLを実行して、ほんちゃんのクエリを実行 20万文字を上限とするように設定(かなりの余力を持つ) MySQL5.7ではデフォルト値1024らしいので、それ以降のバージョンも多分同じでしょう。 |
|
2021 09,03 15:27 |
|
テーブル1でselect した結果を、テーブル2へ更新(update)するということ
まれに対応しないといけないことがあり、忘れるので。 https://www.projectgroup.info/tips/MySQL/SQL/SQL000001.html こちらのページがシンプルで分かりやすい 転記させていただくと UPDATE TableA
,TableB
SET TavleA.Column1 = T2.Column1
,TavleA.Column2 = T2.Column2
WHERE TableA.ID = TableB.ID
UPDATE TableA
,(SELECT tableB.ID
,tableB.column01
FROM tableB t3
WHERE tableB.ID = 10
) W_TableB
SET TableA.column01 = W_TableB.column01
WHERE TableA.ID = W_TableB.ID
というような形 |
|
2020 12,14 17:13 |
|
結論、デフォルトでは出来ません。。。
いろいろ調べた結果、この結果 でもね、世の中には同じような人がいるんですね。 https://gist.github.com/kijtra/3074750 をMySQLの関数(function)としてくれば、除去してくれるんです。 でも、これだと対象のカラムが、nullだったり、空だったりするとエラーになったのです。 なので、上記の関数をもとに、nullだったら、処理をしないという処理を追加 (処理ってほど偉そうなもんじゃないです。) DELIMITER //
DROP FUNCTION IF EXISTS `STRIP_TAGS`//
CREATE FUNCTION STRIP_TAGS( x longtext) RETURNS longtext
LANGUAGE SQL NOT DETERMINISTIC READS SQL DATA
BEGIN
DECLARE sstart INT UNSIGNED;
DECLARE ends INT UNSIGNED;
IF x IS NOT NULL THEN
IF x != "" THEN
SET sstart = LOCATE('<', x, 1);
REPEAT
SET ends = LOCATE('>', x, sstart);
SET x = CONCAT(SUBSTRING( x, 1 ,sstart -1) ,SUBSTRING(x, ends +1 )) ;
SET sstart = LOCATE('<', x, 1);
UNTIL sstart < 1
END REPEAT;
END IF
END IF;
RETURN x;
END;
// IF文を追加しただけ kijtraさんに、感謝です。 |
|
2018 10,27 00:32 |
|
今の現場でデットロックが起きたようで
なんでか、こっちに軽く飛び火 はっきり言って、そういう設計だから、そうなるんだよって話がある 今回起きた原因としては、SELECT FOR UPDATEの部分のようで 詳しくソースを追っていないので、正直原因は分かりません。 ただ、「SELECT FOR UPDATE」という文法を、何も考えずに使うとはまりそうなので 今後のために残す。 (基本、この文法はあまり使わないです、私は) 当然ながら、MyISAMでは利用できない これが、うっかり忘れそう トランザクションの中で利用しないと、SELECT FOR UPDATEをした時に行ロックがかかりません。結果、普通のSELECTと変わらなくなってしまいます。
ちょっと考えれば、当然ですよね。UPDATEするんだもん。 でも、SELECTと記述しているから、トランザクションを忘れることもありそうなので。 一意に取得できないクエリを発行したりすると、ギャップロックやネクストキーロックが発生する(簡単に言うと、特定範囲の行が一気にロックされる)ことがあるようです。 なので、ロックした後は、速やかに情報を更新してコミットする。 SELECT FOR UPDATEをしている時点で、結構更新頻度が高めのテーブルを操作しているはずです。例外発生時などに、きちんとrollback等で後始末をしないと、デッドロックが起こってパフォーマンスが落ちます。 |
|
忍者ブログ [PR] |