MySQL 8.0.32にはUNION ALLをするとWHERE句で日本語が使えなくなるバグが存在します | DevelopersIO
データアナリティクス事業本部のueharaです。 今回は、MySQL 8.0.32でテーブルをUNION ALLした際に生じるバグを共有したいと思います。 バグの事象 こちらで報告されている通り、MySQL 8.0.32では、UNION ALLをするとWHERE句で検索条件として日本語を指定すると、以下のようなエラーが発生して処理が落ちてしまいます。 Cannot convert string '\xE5\x8C\x97\xE6\xB5\xB7...' from utf8mb4 to binary したがって、次のような処理をすることが不可能になります。 WITH tmp_table AS ( SELECT name, data1 FROM table_a UNION ALL SELECT name, data1 FROM table_b ) SELECT * FROM tmp_table
Aurora MySQL でレコードが存在するのに SELECT すると Empty set が返ってくる事象を調査した話
こんにちは。 KINTO テクノロジーズの DBRE チーム所属のp2skです。 DBRE（Database Reliability Engineering）チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE の取り組み例としては、あわっち（@_awache）による DBRE ガードレール構想の実現に向けた取り組みについてというテックブログや、今年の AWS Summit の登壇内容を是非ご覧ください。 今回の記事は、データベースに関する課題解決の事例として「Aurora MySQL でレコードが存在するのに
100秒でMySQLのローカル環境をDockerで作って、データも自動で入れる。最強のSQL練習環境構築法
【2022/2/26 追記】 主にはてブコメントで様々なご指摘を頂いたので、タイトルの修正＆内容を一部追記しました。分かりにくいタイトルを付けてしまい申し訳ございません。ご指摘ありがとうございます。 もともと本記事は自分用のメモを兼ねて駆け出しエンジニアの人が数人参考にしてくれたらいいかな、程度の気持ちで書いたものでした。 現在はてなブックマークのテクノロジーカテゴリーで 1 位になっており、予想の 1000 倍以上の人に見ていただける記事になってしまいました。 今後も精進します、ありがとうございます！ 特に理由もなくローカルに MySQL を入れて遊びたくなる気持ちって定期的に湧きますよね。 私は湧きます、半年に 1 回ぐらい。 業務ではフロントを触ることが多く、DB はそれほど触りません。 そのため久々に MySQL をローカルで立ち上げようとするといつも手順を忘れてしまっていて、なん
MySQLでIN句の中に大量の値の入ったクエリがフルスキャンを起こす話 - freee Developers Hub
こんにちは、freee Developers Advent Calendar 2021、19日目のid:shallow1729です。昨日はtdtdsさんで【マジで】サイバー演習シナリオの作り方【怖い】でした！障害訓練後に攻撃方法を解説された時はリアリティの高さに驚きました。 僕はMySQLを使っていて発生した不思議な挙動の調査の話をしようと思います。 今回問題となったクエリ 今回話題にするクエリは以下のようなシンプルなものです。 SELECT * FROM hoge WHERE id IN (...) MySQLのパラメーター次第ですが、デフォルトの設定だとこのIN句の中の値の数が数万になると適切なインデックスが用意されていてもフルスキャンが発生する事がありました。このクエリがテーブルのほとんどのレコードを網羅するような場合や高速でレコードを大量にinsertして統計情報が追いつかないケー
MySQL で使用するメモリサイズの見積もり - 元RX-7乗りの適当な日々
最近、MySQLのパラメータの調整をする機会があったのですが、特定のパラメータを変更した際に、メモリの消費量にどう影響するのか、というのを調査する際に、インターネッツを彷徨ったところ、サイトによって書いてあることにバラつきがあったので、自分でもまとめてみることにした。 結論から書くと、参考にしたのは以下のオライリーの書籍「MySQLトラブルシューティング」で、記述が一番わかりやすく書かれていた。 このエントリは、この書籍の 「3.9.3 オプションの安全値を計算する」 にて記載がある内容をまとめたものになる。 MySQLトラブルシューティング 作者:Sveta SmirnovaオライリージャパンAmazon 著者について Sveta Smirnova(スヴェータ・スミルノヴァ): Oracle社MySQLサポートグループ・バグ検証グループの主席テクニカルサポートエンジニアとして毎日MySQ
とあるテーブルの中身を一括更新した話から学ぶPITR - Qiita
この記事は本番環境でやらかしちゃった人のアドベントカレンダー9日目の記事です。 https://qiita.com/advent-calendar/2020/yarakashi-production 去年に引き続き、今年も参加させてもらいました。 ※去年の記事はこちら→ データ移行をしただけなのに…（起こってしまったメール誤配信） 今年のネタも15年くらい前の事で、且つ自分が直接関わった事案ではないのですが、「そういやあの事件、今MySQLだったらどうするかな」と思い書くことにしました。 何があったか もうタイトルで出落ちしていますが本番でUPDATE文を実行する際にWHERE句を付け忘れたという事故です。 当時の状況を整理するとこんな感じだったと思います。 対象サービス： 年商10億円くらいの自社サービス 作業内容： 仮登録されている顧客の情報を指定された情報で更新する 作業環境： DB
MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump で絵文字が消えていないか要チェック mysqldump が Error 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク
MySQLで3億レコード物理削除した話 - Qiita
はじめに こんにちは。webエンジニア社会人をしている ningenMe です。 タイトル通り。MySQLで3億レコード物理削除した話。 ちょっとハマったので備忘録。 はじまりはアラート はじまりはアラートだった。 僕が運用・保守しているバッチサーバでは、mysqlからちょうど直近1ヶ月分のデータを毎日1回selectする定期処理をしている。 いつもなら1時間程度で終わる処理のはずが、その日は7,8時間経っても終わらずアラートが鳴り止まない.....。 原因追求 とりあえずリトライしたり、ログ見たりしたもののあんまり悪いところがなかった。 クエリもちゃんとindex効いてる。なんでだろうと思ったらDBの容量が結構大きくなっていたことに気づいた。 3億5千レコード。インデックスちゃんと効いてたので多分普通に遅いだけっぽい。 必要なデータ取得は1ヶ月分である12'000'000件ほど。このse
MySQL 5.7 のONLY_FULL_GROUP_BY が出た時にDockerでやった対処 - Qiita
MySQL5.7のExtended Supportは２０２３年１０月までです。これから始める場合はMySQL8.0を使いましょう。 既存のシステムのMySQLを5.6から5.7に変えて動かしたら、group by を使ったSQLでエラーが発生した。 Error Number: 1055 Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'dtabase_name.table_name.column_name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by このエラーは s
スイッチ交換でMySQLのレプリケーションが壊れた顛末
2019年8月2日、インフラストラクチャエンジニアやネットワークエンジニア向けの勉強会「インフラ・ネットワークエンジニア勉強会」がアイスタイル株式会社で開催されました。同会では、AWSに関するインフラ・ネットワーク視点の話や、オンプレ環境の話など、過去の事例を共有。6人のエンジニアが成功・失敗談をシェアしました。「スイッチ交換でデータベースがすごく苦労した話」に登壇したのは、株式会社アイスタイルのsuzukito氏。講演資料はこちら スイッチ交換でデータベースがすごく苦労した話 suzukito氏：レイヤ3スイッチの交換でデータベースがすごく苦労した話をしたいと思います。 自己紹介です。鈴木と申します。アイスタイルのデータベースエンジニアをやっています。 お話しすることは、スイッチ交換でMySQLのレプリケーションが壊れました。その顛末を共有したいと思います。 まず、ある日、インフラのほ
MySQLで直感的じゃない動きをするRAND()とSYSDATE()について - なからなLife
端的にいうと SELECTのWHEREの条件の「右辺」に、RAND()やSYSDATE()のような非決定性関数を使うと、想定外のことが起こる。 戻ってくる行数が想定と異なる。 Indexが効かなくなる。（テーブルフルスキャン走る） どっちもなかなかのインパクトです。 追記：2019/05/30 PostgreSQLもMySQLと同じ挙動でした。（9.6と10系で確認） Oracleは、MySQLやPostgreSQLとは異なり、想定通りの件数が返ってきますし、Indexも効いてました。（11g R2で確認） 追記：2019/05/31 「PostgreSQLもMySQLと同じ」なのは、「ランダム関数利用時の挙動」です。日付系は調査しきれてません。 公式ドキュメントを読む限り、clock_timestamp()やtimeofday()を意図的に使わない限り、１つのSQLの中で違う日時を取り直
もし間違ってDROP DATABASEしてしまったら – area[nothing] : diary
2007/ 01 02 03 04 05 06 07 08 09 10 2006/ 01 02 03 04 05 06 07 08 09 10 11 12 2005/ 01 02 03 04 05 06 07 08 09 10 11 12 2004/ 01 02 03 04 05 06 07 08 09 10 11 12 2003/ 01 02 03 04 05 06 07 08 09 10 11 12 2002/ 01 02 03 04 05 06 07 08 09 10 11 12 2001/ 01 02 03 04 05 06 07 08 09 10 11 12 2000/ 01 02 03 04 05 06 07 08 09 10 11 12 1999/ 01 02 03 04 05 06 07 08 09 10 11 12 1998/ 01 02 03 04 05 06 07 0
MySQL 8.0は何が優れていて、どこに注意すべきか。データベース専門家が新機能を徹底解説 - エンジニアHub｜Webエンジニアのキャリアを考える！
MySQL 8.0は何が優れていて、どこに注意すべきか。データベース専門家が新機能を徹底解説 MySQLの最新版「MySQL 8.0」正式版が2018年4月にリリースされました。数多くの機能や設定が追加・変更されているMySQL 8.0の「知っておきたい便利な機能」や「危険なハマりどころ」などを、My SQLの専門家に教えてもらいました。 2018年4月、世界中のエンジニアが待ちに待ったMySQL 8.0の正式版がリリースされました。本リリースに伴い、数多くの機能や設定が追加・変更されており、MySQLがより便利なものへと進化しています。 MySQL 8.0で積極的に利用すべき目玉機能や、知っておかなければ危険なハマりどころなど重要な変更点を、MySQLの保守サポートやコンサルティングなどを専門とする株式会社スマートスタイルの中野真也さんと成田優隆さんに解説してもらいました。 中野真也（な
MySQL 8.0正式版がリリース。性能が最大で2倍、JSONデータや地理情報などサポート。ロールによるユーザー権限の管理も可能に
MySQL 8.0正式版がリリース。性能が最大で2倍、JSONデータや地理情報などサポート。ロールによるユーザー権限の管理も可能に 前バージョンのバージョン番号は5.7で、本バージョンが8.0になったのは、過去のバージョン番号で6が使われたことがあったというMySQL のバージョンの都合や、MySQL Clusterがバージョン7であることなどを考慮したためとされています。 MySQL 8.0では、大幅な性能向上、JSONデータに対応したNoSQL機能の搭載、地理情報の対応、ロールによるユーザー権限など、さまざまな改善が行われています。 性能が最大で2倍に MySQL 8.0では、MySQL 5.7と比較してユーザー数が増えた場合に最大で約2倍ほどの大きな性能向上を実現しています。下記は読み込み性能の比較です。 読み込みだけでなく書き込み性能も向上しており、これはInnoDBでREDOログ
本当はこわいMySQLプロトコル - tmtms のメモ
11/28 に Haskell で MySQL の Xプロトコルを実装したという話が聴ける Club MySQL というイベントがあったので参加してきました。 clubmysql.connpass.com MySQLのプロトコルの話ということで、平日の夜とは言え東京で参加者9人(発表者含む)というマニアックな集まりでした。 自分も1年前に Ruby で MySQL Xプロトコルを実装していたのですが、このツイートを最後に中断していたのでした。 MySQL X Protocol で Collection の追加はできるようになったが、検索がめんどくさい。条件文字列のパースはクライアントで行う必要があるんだな。— とみたまさひろ💎🐬 (@tmtms) 2017年2月20日 今回話を聞いて、無理に謎条件式文字列をパースするんじゃなくて、処理系で書きやすいように書けばいいんだという方式に目から
MySQL 8.0ではデフォルトで濁点半濁点を区別しなくなる - かみぽわーる
4月にMySQL 8.0のUnicodeと日本語対応についてManyi Luさんとディスカッションする会があって、かなりいろいろ話してとてもよい会だった。その後いろいろ考えて感じてる懸念を端的に書き記しておく。 デフォルトのcollationがutf8mb4_0900_ai_ciになった これに関して僕は強い懸念を持っている。MySQL 8.0以前において、ふつうのWebアプリケーションなどで日本語を扱う場合、実用上デフォルトのutf8mb4_general_ciかutf8mb4_binの2択であったと思う。デフォルトがutf8mb4_general_ciなので新しく作られるアプリケーションは通常は濁点半濁点が区別される状態で世に出てくることになる。けどMySQL 8.0.1のデフォルトのutf8mb4_0900_ai_ciは濁点半濁点を区別しないので、将来ユーザー名を登録するところでバイ
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
mysqlをdisる会 - Qiita
はじめに やあ （´・ω・｀) ようこそ、バーボンハウスへ。 このmysqlはサービスだから、まずsystemctl start mysqld して落ち着いて欲しい。 うん、「また」なんだ。済まない。 仏の顔もって言うしね、謝って許してもらおうとも思っていない。 でも、このタイトルを見たとき、君は、きっと言葉では言い表せない 「ときめき」みたいなものを感じてくれたと思う。 殺伐とした世の中で、そういう気持ちを忘れないで欲しい そう思って、この記事をかいたんだ じゃあ、注文を聞こうか。 というわけでmysqlをdisります。disるだけなので内容はありません。いいね？ mysql には罠がいっぱい そうなんですよ罠がいっぱいなんですよ奥さん。 いやこれはおそらくmysqlに限った話ではないんですけど例えばこういうの！ MySQLのチューニングなんてしたらパフォーマンス落ちるだけだし、デフォル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLを割と一人で300台管理する技術
MySQLさんからColumn not foundって言われているけど、ログを見る限りそのカラムはSQLのどこにも出現しない
