2018/05/23 MySQL Innovation Day Tokyo https://eventreg.oracle.com/profile/web/index.cfm?PKwebID=0x551742abcdRead less
mysqlに関するtsucchi1022のブックマーク (126)
-
tsucchi1022 2018/05/29
-
MySQL 8.0は SELECT .. FOR UPDATE SKIP LOCKED とJSON_TABLES関数で「取り敢えずJSON」が捗る？
MySQL 8.0は SELECT .. FOR UPDATE SKIP LOCKED とJSON_TABLES関数で「取り敢えずJSON」が捗る？ TL;DR auto_increment + JSON型（あるいはBLOB型やTEXT型でもいいけど）に生のJSONを突っ込む 後から SELECT .. FOR UPDATE SKIP LOCKED でワーカーが取り出して、 INSERT .. SELECT JSON_TABLE(..) FROM .. で正規化したテーブルに突っ込みなおす 外部APIからの戻りのJSONを取り敢えずログテーブルに格納して…みたいな感じを想像している PoC mysql80 13> SHOW CREATE TABLE t2\G *************************** 1. row *************************** Tab
-
MySQL 5.7新機能解説：レプリケーション、セキュリティ編
今月の頭、詳解MySQL 5.7の出版記念第一弾として、MyNA（日本MySQLユーザ会）名義でイベントを行ったので、その際使用したスライドを紹介しておこう。今回紹介した新機能のカテゴリは2つ。レプリケーションとセキュリティである。レプリケーションはMySQLの運用と切っても切り離せないほど重要なものであり、そしてデータベースサーバーにとってセキュリティが重要であることは、言うまでもないだろう。 今回のバージョンでは、レプリケーションが大きく進化している。 まず、MySQL 5.7では、レプリケーションのトポロジの限界を打ち破った！！MySQL 5.6までのバージョンでは、スレーブはひとつのマスターしか持つことができないという制約があったのだが、それがなくなった。すなわち、スレーブが複数のマスターからデータを連続的に複製することができるようになったのである。それにより、これまで以上に様々な
-
gh-ost: GitHub's online schema migration tool for MySQL
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
-
pt-online-schema-changeと5.6 InnoDBのオンラインALTER TABLE使い分け
この記事は MySQL Casual Advent Calendar 2015 の9日目です。 MySQL 5.6から InnoDBのオンラインDDL が導入されて久しいですが、一方で pt-online-schema-change (以下pt-osc）もまだまだ元気です。MySQL 5.5とそれより前ではpt-osc一択になりますが、MySQL 5.6とそれ以上の場合はInnoDBさんに任せるかpt-oscを使うかを選択することができます。 MySQL 5.6でもpt-osc一択にしても構わないといえば構わないんですが、いくつかのケースではInnoDBさんに任せた方が速くなったり安定したりするので、そのあたり解説していきます。 TL;DR ウチの使い分け。 原則 pt-osc スレーブの台数が多すぎない かつ データ容量が馬鹿でかくてストレージ食いつぶしそう または INSERT大杉で2
-
kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々
インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0
-
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
-
DBT-2 で MySQL と他のRDBMSの性能比較をしている人に騙されないように注意
一応、立場的には第三者に戻った(MySQL/InnoDBの性能追求が仕事ではない)ので、忘れられない暗い過去にも触れてみようと思います。 未だに騙されている人が多いみたいなので、MySQL/InnoDBの名誉のために書き残さなければなりません。何度でも言いますが、性能比較は自分の目的とする処理をちゃんと比較しないとだめです。そうでなくては、騙されて本当は悪い性能のものを掴まされることになります。 DBT-2と言う(TPC-Cをベースにした)ベンチマークがありますが、数多のRDBMS(商用/OSS双方)に対して独自にTPC-Cベンチマークを実装・チューニングして比較した経験のある私から見て、怪しい結果しか出ないので、長年、基本無視のスタンスを取っています。 が、３年前にあろうことかMySQLの性能QAがDBT-2(nonsp:mysql)を利用していて、とある性能FIXに対して問題を指摘して
-
-
大物 alter table の途中で Lost connection to MySQL server during query が発生したときに確認したいこと - Studio3104::BLOG.new
5時間モノの alter table が Lost connection to MySQL server during query したんだけど show processlist するとまだ動いてるっぽいから放置しとけば完遂するのかなと思ってるんだけど大丈夫だろうか、、、 2015-03-30 16:47:05 via Twitter for iPhone とりあえず show processlist してまだ動いてるっぽかったら、datadir 配下で #sql-xxxx_xxxxx.ibd な名前のファイルが育っているかどうか確認する。 タイムスタンプが更新されていればテンポラリテーブルへのデータコピーが生きてるということになるので、あとは show processlist を監視して終わるのを待てば良い。 で、終わったっぽかったら show create table を確認して変更が
-
InnoDB Deep Talk #2 (仮) に引っ張りだされました。
先日、「InnoDB Deep Talk #2 (仮)」というイベントでお話ししてきました。 「事前情報は講演者の名前のみ(内容未定)」という、振り返ってみると異常な状況にも関わらずお集まりいただきありがとうございました。 今回は、前回とは違って少しだけ公開を意識して作ったあったので公開してみます。 これで手持ちのネタは出し尽くしたので、また暫くブログの更新は無いかもしれませんがご容赦を。。。
-
過去、現在、未来、全宇宙に存在する全てのクソクエリーを、生まれる前に自分の手でカジュアルに消し去ること(仮)
過去、現在、未来、全宇宙に存在する全てのクソクエリーを、生まれる前に自分の手でカジュアルに消し去ること(仮) この記事は MySQL Casual Advent Calendar 2014 の3日目の記事です。 クソクエリーについての名言 がつい先週生まれたばかりですが、みなさま如何お過ごしでしょうか。そういえば今年は Kuso-query As A Code みたいな話もさせてもらいました。 過去、現在、未来、全宇宙に存在する全てのクソクエリーを、生まれる前に自分の手でカジュアルに消し去るため(仮)に、MySQL 5.7.5-labsのQuery Rewrite Plugin の記事では触れるだけだったオレオレrewriteプラグインを書いてみました。君のクエリにレボ☆リューション! (仮) どういう動作をさせるかというと、 mysql57> SELECT 1; +---+ | 1 |
-
Google Cloud SQL を雑にMySQLの代用品として利用してみた | All Your Bugs Are Belong To Ass
※このエントリは、MySQL Casual Advent Calendar 2014 の2日目として書かれたものです。12/2(火)現在、まだいくつか枠が残っておりますので、興味のある方はぜひ参加してみてはいかがでしょうか。 ※このエントリに掲載されているGoogle Cloud SQLは課金が必須なサービスです。本文中でも多少触れますが、クレジットカードなしでは試すこともできませんので、ご注意ください。 Google Cloud SQL とは？ 最近クラウド分野に力を入れてきているGoogleですが、かなり前にGoogle Cloud SQL(以下Cloud SQL)をリリースしています。今思い出したかのようにリリース時の記事を検索してみたのですが、@ITによると、2011年11月にサービス提供をしているらしいので、すでに3年経過していることになります(ちなみに正式公開は米国時間の201
-
MySQL のテーブルを BigQuery にインポートするための App::BigQuery::Importer::MySQL - まいんだーのはてなブログ
このエントリは MySQL Casual Advent Calendar 2014 の1日目として書かれた記事であり、同時に Google Cloud Platform Advent Calendar 2014 の17日目として書かれた記事でもあります。 このエントリは MySQL と BigQuery を組み合わせて使う際に誰しも思うであろうことをどう解決するかという一手について書いたものです。 MySQL について もはや説明不要の RDBMS ですね。これを読まれている方の中でも多くの人が使っているのではないでしょうか。 MySQL Casual Advent Calendar 2014 はまだまだ執筆者を募集しておりますので、ふるってご参加ください。 MySQL Casual Advent Calendar 2014 - Qiita BigQuery について こちらも説明は要らな
-
YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
-
MySQLのパラメーターチューニング at OSC 2014 Tokyo/Spring
去る2014/03/01(土)の OSC 2014 Tokyo/Spring でMyNAとしてセミナーの枠をいただいたので、おはなしししてきました。 雨の中たくさんの方に足を運んでいただきました。本当にどうもありがとうございました。 "MySQLパラメーターチューニングの理屈と定石"と銘打って、普段アプリを書いているような人向けに、俺が普段やってるパラメーターチューニングと同じくらいのことが誰にでもできるように…とか思って資料を作っていたんですが(社内のDB勉強会に使うネタのうち、パラメーター調整の部分だけを切り出した、というのがもともとのコンセプトです)、作れば作るほど、いかに自分が「考えるな。感じるんだ」でチューニングしているのかをむしろ思い知らされました。 「これとこれ見るでしょ？ そうするとなんか変な感じがするじゃない？ で、こことここだからこれかなって。いじってみたら違うから、近
-
YappoLogs: DBD::mysql Async API
DBD::mysql Async API MySQL の Async API 使って思いクエリを並列処理したら早いかと思ったらそうでも無い風味。 Web アプリの時のように、クライアント側の並列度があがれば差が縮まる感じだけどそうでもない。 ある程度重いクエリの想定で SELECT SLEEP(0.05) とか投げてみたけどやっぱり普通に使った方が早い。 Async API 使うのにコストがかかるのかな、と思って IO::Select 使ってみたらかなり早くなったので AnyEvent がわりとボトルネックっぽい。 とは言え微妙な誤差ではあるので、普通に DBI 使ってればいい気がしてきた。 perl 5.18.2 DBI 1.63 DBD::mysql 4.025 AnyEvent 7.07 IO::Select 1.21 async-mysql-ioselect.pl が全入りベンチ(
-
cpanmでDBD::mysqlを入れる - Qiita
plenvやperlbrewでcpanmを入れてそれでモジュールを入れるとDBD::mysqlが入らないケースがあります。手元にMySQL (libmysql) が入っていないからです。 Homebrewを使って手元に手軽にMySQLを入れてしまいましょう。 検証環境: MacBook Air 2013 Late Mavericks なお、付記として Debian stable / Ubuntu stable の場合についても言及してあります。 HomebrewでMySQLを入れる 思いつく通りに入れれば大丈夫そうです。 ここでトラブルが起きた場合は brew doctor を参考にするか、brew update を怠っていないかなどをチェックしましょう。HomebrewでMySQL 5.6をインストール。開発用my.cnfもさらす も参考になります。 DBD::mysqlインストール用の
-
-
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました