MySQL :: MySQL 8.0 リファレンスマニュアル :: 24.3.1 RANGE および LIST パーティションの管理
レンジパーティションとリストパーティションの追加および削除は同様の方法で処理されるため、このセクションでは両方のパーティション化の管理について説明します。 ハッシュまたはキーによってパーティション化されたテーブルの管理については、セクション24.3.2「HASH および KEY パーティションの管理」を参照してください。 RANGE または LIST によってパーティション化されたテーブルからパーティションを削除するには、DROP PARTITION オプションを指定した ALTER TABLE ステートメントを使用します。 レンジでパーティション化され、次の CREATE TABLE および INSERT ステートメントを使用して 10 個のレコードが移入されるテーブルを作成したとします: mysql> CREATE TABLE tr (id INT, name VARCHAR(50),
【MySQL】大量データで LIMIT と OFFSET を使うと遅い - pospomeのプログラミング日記
1000万件くらいのテーブルがあって、 そこから LIMIT OFFSET でデータを取得するんだけど、 OFFSET の値が大きければ大きいほど、遅くなる。 なぜ遅いのか? と思って EXPLAIN を実行したところ、 LIMIT OFFSET は テーブルフルスキャン(ALL) だった・・・。 なんとなくインデックスが効いているものだと思ってたが、 そうでもなかった。 --- 追記 2014/11/10 --- コメントにて 「ALLになるのは、何らかのキーでソートしないとALLになります」 とのご指摘をいただきました。 ---------------------- --- 追記 2014/06/13 --- なぜかこの記事の閲覧数が増えていたので内容を再確認してみました。 レコード数が多くなると LIMIT OFFSET が遅いというのは間違いないと思う。 ただ、上記の「LIMIT
MySQL トランザクション - とみぞーノート
トランザクションを使うと複数のクエリをまとめて１つの処理として扱うことができる。処理の途中でエラーになって処理を取り消したいような場合はROLLBACKをすることで変更内容を元に戻すことができる。 トランザクションはデフォルトのMyISAM形式のテーブルでは使用できない。トランザクションが使用できるテーブルにはInnoDB,BDBなどがある。以下ではInnoDBを使って説明する。 1.InnoDBテーブルの作成 新規に作るテーブルをInnoDBにするには、以下のようにする。 mysql> CREATE TABLE friends (id SERIAL, name VARCHAR(30) NOT NULL, address VARCHAR(100), birthday DATETIME) TYPE=InnoDB; 既存のテーブルをInnoDBに変更する場合は以下のとおり。 mysql> AL
Mroongaを使って全文検索Webサービスを作ったときにはまったこと(第1回) - CreateField Blog
前回のエントリに書いたように、１年半ほどをかけて、独学で特許の全文検索サービスを開発しました。 PatentField | 無料特許検索 最初は、MySQLを使ったこともない状態だったこともあり、かなり紆余曲折しました。Groonga開発チームの懇切な対応もあって、専用サーバ1台で最大で1千万レコード超、400GiB以上のサイズのテキストデータを高速に検索できるようになりました。 今後、何回かにわけて、Mroonga(Groonga)を使って全文検索Webサービスを作ったときにはまったこと、学んだことを全て書き出したいと思います。 全文検索エンジンMroongaとは？ Mroongaは全文検索エンジンであるGroongaをベースとしたMySQL用のストレージエンジンです。Mroongaは、MySQLが使える人であれば、簡単に高速な全文検索機能が使えます。MariaDB10.0系にもバンドル
データベースとSQLの業務スキルレベル 判別表 （５段階） - 主に言語とシステム開発に関して
スキルチェックの目次へ リレーショナル・データベースを利用したシステム開発の，簡易スキルチェックのための調査表。印刷用。 データベース・エンジニアのレベルを測定する。 レベルは，０から４までの５段階。 （０） 非エンジニア （１） 初学者（入門書を学習してゆく段階） （２） ノーマル（基礎的な知識があり，ある程度の動くものを作れるようになった段階） （３） 中級者（開発プロジェクトで１人月としてカウントできる水準） （４） 上級者（メインPG/メンターとして，主設計を任せられる水準） Webアプリのプロジェクト開始時に作業振り分けをするにあたって，新規メンバ全員にこれを渡して回答してもらうという用途を想定。 なお，開発上のスキルをチェックする事が主眼なので，DBAとしての技量はあまり考慮しない。 下記で「自分に当てはまる項目が最も多いレベルが，自分の属するレベルである」とする。 ※ただし，
第1回 全文検索エンジンgroongaを紹介します！ | gihyo.jp
今回から始まった隔週連載groongaでは、groongaを使いたくなるような情報を隔週毎にお届けします。 groongaとはGitHubで公開されているオープンソースの全文検索エンジンです。大量にある文書の中から目的のキーワードを持つ文書を高速に見つけることができます。 groongaのロゴ©groongaプロジェクト 第1回目である今回は、この連載についてとgroongaの特徴を紹介します。 この連載について まず、この連載について説明します。 この連載は「読者の皆さんがgroongaを使いたくなる！」ことを目指しています。そのために、次の2点の情報を次回から交互にお届けします。 groongaの利用事例の紹介 利用事例に関連した役立つ情報の紹介 利用事例を紹介することで、「あそこでも使っているなら自分も使ってみようかなぁ」とか「こんな使い方をしているなら自分も使ってみようかなぁ」と
MySQLのクエリ集計手法いろいろ | Ore no homepage
Webサービスを開発/運用してるモンとしては、いろんなWebサービスを触ってみなきゃアカンってことで、アメリカの若モンに大人気ってふれこみのsnapchatに登録してみた。これでリア充の仲間入りやと思ったが、snapchat友達が同僚二人しかいないうえに、利用シーンがあまり思い浮かばないww オジサン困っちゃいました。画像とか送信できるんだけど、数秒で消えるの。むしろそこがウリっていうね。どうやって遊ぼうか…。 2月はブログ書かなかったなーと思ったのでMySQL小ネタ。世間的にも自分的にも真新しくもなんともないTipsです。 innotopで集計 実は以前、Qiitaに書いたので↓をば。。。 http://qiita.com/la_luna_azul/items/505ca441b8c8e6a87aaa 流れるクエリ、ロックの状況、トランザクション(show engine innodb s
login
ナップザックは、システム開発／ソフトウェア開発の設計・開発事務所です。 株式会社ナップザック © 2013-2018 NAPZAK Inc.
MySQLでMyISAMからInnoDBに乗り換える際に知らないとハマる、怖い話 - Y-Ken Studio
photo by byte MySQLといえば、巷ではInnoDBばかり注目され、MyISAMの地下アイドル化がにわかに語られる今日この頃、皆様いかがお過ごしでしょうか。 まあカジュアルにストレージエンジンを変換するだけで済むなら、簡単なのです。 -- legacy_my_tableをInnoDBストレージエンジンに変換する ALTER TABLE legacy_my_table ENGINE=InnoDB; よし終わった！さあランチタイムだ！ ・・・と片付けてしてしまうと、悲劇が起こるかもしれません。(>o<;) それでは本日、MyISAMからInnoDBへ移行するなら知っておきたい意外な落とし穴とTipsを紹介します。 AUTO INCREMENTの挙動が違う落とし穴 以下に該当するクエリを利用している場合には、注意が必要です。私はハマりました。 INSERT IGNORE INTO
実践 ハイパフォーマンスMySQL(第2版)を斜め読みして前半の重要なポイントだけをまとめてみた - Y's note
実践ハイパフォーマンスMySQL 第2版 作者: Baron Schwartz,Peter Zaitsev,Vadim Tkachenko,Jeremy D. Zawodny,Arjen Lentz,Derek J. Balling,伊藤直也(監訳),田中慎司(監訳),吉川英興(監訳),株式会社クイープ出版社/メーカー: オライリージャパン発売日: 2009/12/14メディア: 大型本購入: 17人 クリック: 373回この商品を含むブログ (46件) を見る 実践ハイパフォーマンスMySQLですがMySQL開発者にとっては誰もが目を通しておいた方が良いと推薦される本なので重要なポイントだけをまとめてみたいと思います。まだ前半しか読んでいませんがMySQLの細かいテクニックが載っていて感動です。全部で700ページ近くある本なので斜め読みをした結果を載せて行きます。内容としては実践的なもの
@nippondanji 氏の「データベース設計徹底指南！！」は神プレゼン！脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件！ - #garagekidztweetz
ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました！ 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース（以下RDB）は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
MySQL5.6関連情報まとめ
5. バグ情報など GTID有効でネットワークが途切れるとデータ消失する InnoDBmemcacheAPIのメモリリーク（ #68530 ） GRANT文発行時、構文に特定の記載ミスがあるとレプリ ケーションが停止する（ # 68892） マッチしないパーティションがたくさんある場合、予想ス キャン件数を過剰に低く見積もってしまう不具合 ※上記は勉強会で見かけた情報などです 僕らのMySQL5.6移行記(仮) http://www.slideshare.net/conmame/mysql56-27565355 7. 運用方法の変化について GTIDが有効だとSlaveでクエリをスキップできなくなって確認 して空コミットしないといけなくなった（割と手間） MySQL Utilityというpythonツールが便利そう バッファプールのダンプとリスト
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
PDO、PEAR::DB、MySQL関数の速度比較
サーバー側の問題もあるので、毎回安定した処理結果は得られませんでしたが、大体上表のような結果になりました。 やはりネイティブ関数は速く、mysqli関数が一番速い結果になりました。 続いて同じくネイティブ関数のmysql関数が続き、その次にPDOという結果になりました。 PDOでは、プリペアドステートメントを用いてSQLを発行したため、2回目のSQLの発行ではキャッシュが効き、劇的な速さになっています。 一番遅かったのは予想通り、PEAR::DBでした。 ネイティブ関数よりも2〜3倍遅く、PDOよりも2倍近く遅い結果となりました。 PHP用アクセラレータを導入していなければ、PEAR::DBはもっと遅くなっただろうと考えられます。 まとめ PHP5を利用していて、DBの抽象化を行いたいのであれば、PEAR系のモジュールはやめてPDOにした方が良いと言えます。 単純なSELECT文の結果でさ
MySQL | Oracle 日本
MySQL 5.7 Database Administrator 試験対策ポイント解説セミナー MySQLのデータベース管理者技術を証明する「Oracle Certified Professional MySQL 5.7 Database Administrator」資格対応試験である MySQL 5.7 Database Administrator (1Z0-888-JPN) の出題範囲や学習のポイントを、サンプル問題を交えてわかりやすくご説明します。 MySQL 5.7 Database Administrator 試験対策ポイント解説セミナー パート1 MySQL 5.7 Database Administrator 試験対策ポイント解説セミナー パート2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL生みの親のMichael "Monty" Widenius氏に訊く「MySQLとMariaDB」
MySQLのエラーメッセージ「#1071 - specified key was too long; max key length is 1000 bytes」
データベース設計徹底指南
