https://developer.hatenastaff.com/entry/2019/01/15/120431
db tech showcase Tokyo 2018 - MySQL・PostgreSQLだけで作る高速あいまい全文検索システム #dbts2018 - 2018-09-20 - ククログ
関連リンク： スライド（Rabbit Slide Show） スライド（SlideShare） リポジトリー 内容 去年は「MySQL・PostgreSQLだけで作る高速でリッチな全文検索システム」というタイトルで話しました。去年はMySQL（Mroonga）・PostgreSQL（PGroonga）で次のことを実現するための具体的なSQLを紹介しました。 全文検索 キーワードハイライト 周辺テキスト表示 入力補完 同義語展開 関連文書の表示 構造化データ（オフィス文書・HTML・PDFなど）対応 今年は「MySQL・PostgreSQLだけで作る高速あいまい全文検索システム」というタイトルで話しました。今年も話の流れは同じにしました。あることを実現する具体的なSQLを紹介するというスタイルです。今年はMySQL（Mroonga）・PostgreSQL（PGroonga）で次のことを実現す
LAST_INSERT_IDを使って採番テーブルを扱う - (ﾟ∀ﾟ)o彡 sasata299's blog
2009年07月06日22:54 MySQL LAST_INSERT_IDを使って採番テーブルを扱う 採番テーブルというのは、例えば同じ DB の違うテーブル（data_1テーブルとdata_2テーブルとか）で id を重複させたくない（つまり、data_1テーブル、data_2テーブルでは auto_increment は付けない）場合などに、ユニークな id を生成するためのテーブルです。こんな感じ。 CREATE TABLE num ( id bigint(20) unsigned NOT NULL DEFAULT '0' ) ENGINE=InnoDB; +-------+---------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---
CHECK制約をエミュレートする新旧の方法とドメイン (MySQL Server Blogより) | Yakst
MySQLではCHECK制約をサポートしていないが、これをエミュレートし同等の機能を実現する方法がいくつかある。旧来のトリガーやビューを使った方法に加え、MySQL 5.7の新機能である生成列を使った方法を紹介する。 免責事項 この記事はGuilhem Bichot氏によるMySQL Server Blogの投稿「New and old ways to emulate CHECK constraints, DOMAIN」(2016/2/2)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 データの正しさを保つには様々な方法があります。1つは参照整合性で、外部キーとして知られているものです。他の方法として、CHECK制約があります。MySQLでは外部キーをサポートしていますが、CHECK制約をサポートしていません。本日は、これをエミュレートする3つの方法についてみていきた
JSON型にindexも！MySQL 5.7のGenerated Columnsの可能性について探る - UUUMエンジニアブログ
nazoです。 今回はMySQL 5.7の新機能であるGenerated Columnsについて紹介したいと思います。 Generated Columnsとは？ 簡単に言うと、トリガーで特定のカラムにデータを入れるのを簡単に定義する方法みたいなもので、カラム定義時にAS 計算式と書くことで、そのカラムの値が該当の計算結果になります。 この機能はMySQL 5.7.6から追加されました。日本語では「生成列」と呼ぶこともあるようです。 基本的な使い方 リファレンスに書いてあるクエリを実行してみましょう。 mysql> CREATE TABLE triangle ( -> sidea DOUBLE, -> sideb DOUBLE, -> sidec DOUBLE AS (SQRT(sidea * sidea + sideb * sideb)) -> ); Query OK, 0 rows af
サイボウズ版 MySQL パフォーマンスチューニングとその結果 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。先日親知らずを抜歯した時、つらすぎたので MySQL の JOIN のことを考えて心の平静を保っていました。 サイボウズの製品のひとつである kintone はニーズに応じて自由に業務アプリのようなものを手軽に作ることができ、データの検索条件やソート条件も細かくカスタマイズ可能で、様々なレベルでのアクセス権も設定可能という非常に便利なツールです。 しかしその機能を支える裏側では複雑なクエリが発行され、MySQL に多大な負荷をかけています。サイボウズのクラウドには数十テラバイトに登る MySQL データがあり、数千万件オーダーのテーブルを複数 JOIN するクエリが毎秒のように実行されるという、エンジニア魂が滾る環境です。 現在サイボウズでは性能改善に力を入れており、僕もその業務に従事しています。例えば2018年
MySQL ってクソだよね - Qiita
CREATE TABLE tbl_unique_test ( id INTEGER NOT NULL, value INTEGER NOT NULL DEFAULT 0, PRIMARY KEY (id) ); 挿入してみます。 mysql> INSERT INTO tbl_unique_test VALUES (1,1); Query OK, 1 row affected (0.50 sec) 同じクエリをもう一回叩いてみます。 mysql> INSERT INTO tbl_unique_test VALUES (1,1); ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY' はい。 IGNORE を指定してみます。 mysql> INSERT IGNORE INTO tbl_unique_test VALUES (1,1)
MySQLのFLOAT型を使う理由が見つからない件 - hnwの日記
MySQLのデータ型としてFLOAT型という型があるのですが、これを採用するのは混乱の元ではないか？と感じたので、その詳細を紹介します。 そもそもこの話のきっかけは「MySQLで6桁までの小数点を丸めずに扱うならFLOAT型を使うべき理由」という記事が目に止まったことです。それなりに人気を集めている記事のようですが、私の読んだ限りではFLOAT型を使うだけの根拠が文中から読み取れず、さらに類似する一次情報や英語記事が全く見つからなかったので、真偽が怪しい情報だと感じました。 その後、MySQL上で実験したりCソースコードを読んでみたりした結果、私の得た結論は真逆のものになりました。MySQL警察の方や浮動小数点数警察の方、追試や反論など頂けると助かります。 MySQLのFLOAT型とは MySQLのFLOAT型は原則としてIEEE754浮動小数点数単精度型（32bit）で実現されます*1。
MySQLバージョンアップのベストプラクティス | Yakst
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアによる、MySQLバージョンアップの様々なパターンと、その利点・欠点、手順の解説。バージョンアップ実施前の、事前調査とテストが重要であるとの指摘も。 MySQLのバージョンアップ(訳注 : 原文ではupgrade、以下同じ)はどこかで必要になるタスクだし、我々Percona SupportでもMySQLバージョンアップのベストプラクティスについての色々な質問を受け付けている。この記事では、色々なシナリオにおけるMySQLバージョンアップの推奨できる方法に焦点を当ててみたい。 MySQLのバージョンアップはなぜ必要になってしまうのか？その理由は色々だが、新機能が必要、パフォーマンスの改善、バグ修正などがあるだろう。しかし、アプリケーションと組み合わせた上で事前に広範囲なテストをしておかないと、リスクの大きい
MySQL 5.7 の全文検索で不正確な郵便番号に立ち向かう - Qiita
OPENLOGI Advent Calendar 2017- Qiita の6日目の記事です。 「物流の未来を、動かす。」をミッションに、日夜物流の課題に取り組んでいるOPENLOGIのエンジニアの@hmarui66です。 今回は皆さんにも身近な存在である「郵便番号」を取り上げようと思います。 OPENLOGIが取り組んでいる事業の一つである物流代行サービスでは、ECなどで販売された商品を購入者に向けて宅配便で発送する業務がおこなわれています。郵便番号はこの宅配において重要な役割を果たしている存在です。 郵便番号の役割 Wikipedia: 郵便番号に詳しい説明が載っていますので、ここでは軽く触れるだけにします。 郵便番号は郵便物を配送先の地域ごとに分類するために使われており、配送の効率を上げるために役立てられています。番号を割り振っているのは郵便局ですが、その他の配送業者でも広く利用され
MySQLの文字コードをutf8mb4に変更 - Qiita
+--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8mb4 | | character_set_connection | utf8mb4 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8mb4 | | character_set_server | utf8mb4 | | character_set_system | utf8mb4 | | char
いつどのようにInnoDBを共通テーブルスペースから移動するか | Yakst
InnoDBで共通テーブルスペースにデータを格納した場合にデータファイルが肥大化する問題の解決手段について実例を交えて紹介する。 August 22, 2014 by Fernando Laudares 先の投稿「MySQLのibdata1ディスクスペースの問題と大きなテーブルについて詳しくみる」で、 共通テーブルスペースと呼ばれるところに属する大きなテーブルを持つという観点から、ibdata1の肥大化問題についてみた。 先の投稿をする動機となった特定のケースでは、サーバー上のディスクスペースが枯渇し、ibdata1ファイルを縮小する方法を探している顧客がいた。 ご存じの通り、そのファイル(または、共有テーブルスペースを構成するibdataファイル一式)は、 innodb_file_per_tableが無効になっているとき全てのInnoDBのテーブルのデータを格納するだけでなく、 UNDO
テーブル最適化(や大量のDELETE)をほぼ無停止で行う | Gumu-Lab.
MySQLだとDELETEがとても重いです。10000件程度なら余裕ですが、100000件、1000000件にもなると手のつけようがないレベルです。その間MyISAMだとテーブルロックがかかるし、DELETEしすぎると今度は断片化してOPTIMIZE TABLEでもしないと速度低下が始まります。 OPTIMIZE TABLEやALTER TABLEはものすごく時間がかかることがあるんですよね。今回DELETEしようとしたテーブルはWebでの表示に必須の部分でして、どうせならWebをできるだけ落とさずにやってみるかという挑戦でした。 今回DELETEするのは27000000件くらいです。無理です。 処理を一度にできないと踏んだので、DELETEを増加量より多いLIMITで走らせればだんだんと減っていくのではないかと考え、実行。 ごり押しでLIMIT指定で絞ったDELETEを走らせた結果900
たった3秒でInnoDBのデータローディングが快適になるライフハック
MySQLに限った話ではないが、データベース管理システムに大量のデータを投入するのは時間が掛かり大変苦痛を伴う作業である。劇的に効能があるわけではないが、MySQLを利用しているとき、特にInnoDBを使っている場合にはデータの投入を高速化するためにいくつかテクニックがあるので紹介しよう。皆さんの作業時間が短縮され、少しでも早く帰路に着いたりサービスインさせたりという形でお役に立てれば幸いである。ちなみに、タイトルはネタであるのだが、もし本当に3秒で以下の全ての設定を行えた人が居たら教えて頂きたい！ ログファイルサイズの調整データ投入時に限った話ではないが、ログファイルサイズを調整するのは更新性能にとって非常に重要なファクターである。バッファプールのサイズが重要なことに代わりはないが、同じぐらいログファイルのサイズも重要である。InnoDBはログファイルを使い切ってしまうと、バッファプール
MySQL大量データの削除 - Qiita
いきさつ レポート用として1時間毎にデータを作成しているのですが、レコード数が増え続けた結果、ストレージが予想以上に減ってました。 しかも、このままのペースで減ると、3ヶ月後には残ストレージがゼロに。。。 現状の確認 MySQLのバージョンは5.6.34です。 RDSのt2.smallで起動しています。 まずは下記SQLでサイズの大きいテーブルを確認 SELECT table_name, table_rows, ROUND((data_length + index_length) / 1024 / 1024) AS total_size_MB, -- 合計サイズ ROUND(data_length / 1024 / 1024) AS data_size_MB, -- データサイズ ROUND(index_length / 1024 / 1024) AS index_size_MB -- イ
PHPのmysqlndの圧縮プロトコルについてのメモ - hnwの日記
PHP+PDO+MySQLの環境では、PHP-MySQL間の通信についてzlibを使った圧縮プロトコルを利用することができます。この機能は、DBサーバのCPU利用率に十分余裕があり、かつPHP-MySQL間のネットワーク帯域が逼迫している状況で有用です。 MySQLの圧縮プロトコルとそのマニュアル PHP+MySQLの環境で、圧縮プロトコルは下記のようなコードで利用できます。 <?php $options = [ PDO::MYSQL_ATTR_COMPRESS => true ]; $db = new PDO($dsn, $user, $pass, $options); MySQLドライバとしてmysqlndを利用している場合*1、PHP 5.3.11（2012年4月リリース）以降であれば圧縮プロトコルに対応しています。このことはPHPマニュアルにも下記の通り記載があります。 PDO::
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - schemalex/schemalex: Generate difference sql of two mysql schema
MySQLのGIS機能とか超入門 ～MyNA会2018年7月
MySQLを割と一人で300台管理する技術
