漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い（テーブルの行数を保持してる）のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
フォントは自由に変えられる。だから絵文字で何かを伝えるのはナンセンス。そんなことも分からなかったのか、Googleよ。
Unicodeに絵文字が多数追加されたことは、以前から批判していたのだが、やはりというか何と言うか、しょっぱい問題が起こりつつある。 macOS SierraやiOS 10でピストル絵文字🔫が水鉄砲に変わることで起こる問題。 | AAPL Ch. 絵文字はフォント次第で形が変わる。故にフォントが変わればニュアンスも変わる。自分と相手、あるいは今使っている機種と将来使う機種が同じフォントを使っているとは限らない。だからフォントを変更することで様々な問題が起きるわけである。 根本的な問題＝性質が異なるものを混ぜてしまった文字と絵は本質的に性質が違う。 文字はその見た目ではなく、文字を組み合わせた単語、単語を並べた文章によって意味を持つ。フォントが違っても、見た目の違いはあれど、文章そのものの意味は変わらない。どのようなフォントで読んでも意味は通じるのである。 ところが、絵文字はそうは行かない
新たなOSX安全神話の検証：Sandboxでウィルススキャンは不要になるか？
アップルし・・・、もといファンで知られる中島聡氏が、「防備を固める OS X と、無防備な Android と」というエントリを綴っている。中島氏のブログは同意できるエントリも多いのだが、なぜかアップルが絡むとおかしな展開になることがあり、首をかしげてしまう。 今回のエントリでは、「将来的にアップルはOSXにサンドボックスを搭載するらしい」という話から始まって、なぜか「セキュリティの問題がAndroid陣営にとって最大の悩みの種に発展するだろう」という予測で締めくくられている。マジデスカ！！というツッコミが筆者の脳内を駆け巡り、脳内でツッコミが醸成されてネタとなったので、その成分を精製して皆さんにお届けしたいと思う。 サンドボックスとはサンドボックスの機能は特別新しいものではない。コンセプトとしては「プログラムがアクセス可能なコンピュータ資源、例えばファイルやネットワーク通信などを制限する
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
あの超オスもセパレート式キーボードを使ってるらしい（ErgoDoxじゃないけど）
超オス。それは漫画、バキシリーズで登場する単語であり、常人離れした、規格外の体格を持った格闘家を指すときに使われる。そんな超オスがIT業界にも存在する。いや、あまりにも有名なので、恐らく業界人であればその名を知らぬ人は居ないだろう。そう、ウェブ魚拓の開発者、新沼大樹氏である。はっきり言って、IT業界で新沼氏を知らなかったらモグリだと言って差し支えない。それどころか、その名はIT業界だけで収まらず、アスリートたちの間でも広まっている。なんせ、握力日本一である。CoCのNo.4（166kg相当）をコンスタントに閉じられるということなので、もしかすると世界一かも知れない。（参考：IRONMAN BLOG:新沼大樹氏、未公開写真、握力王 新沼大樹氏 テレビ出演 - YouTube） 実は、そんな新沼氏から衝撃の発言を聞いた。 「私もセパレート式のキーボードを使っています。」 ・・・ 〜〜〜〜〜〜〜
MySQL・PostgreSQLユーザーグループ（MyNA・JPUG）合同DB勉強会で発表した資料を公開しました。「データモデルについて知っておくべき7つのこと 〜NoSQLに手を出す前に〜」
表題の通り、MyNAとJPUGの合同DB勉強会で発表をしたので資料を公開した。 内容の詳細はスライドそのものを見ていただくとして、言いたいことの主旨はこうである。世の中に完璧なデータモデルはないので、NoSQLは当然の如く必要になる。だが、何でもかんでもNoSQLを使えば良いというものではない。むしろアプリケーションが必要としているデータモデルが何かということをよく理解し、本当に必要な場合にこそ、NoSQLを使うべきなのである。つまり「ご利用は計画的に！」ということだ。 大切なのは、様々なデータモデルを理解し、アプリケーションにとってベストな製品を選択するということだ。ベストなのがRDBかも知れないし、そうでないかも知れない。最適なデータモデルを選択した場合に、出来上がったものの性能も最高になるし、開発効率も最も良くなる。データベースの主流はRDBだが、それはリレーショナルモデルがカバーで
一般の職務で残業代を０にしてはいけない理由。あるいは０にするための要件。
｢ヒラ社員も残業代ゼロ｣構想の全内幕という記事が注目を集めている。そこでは、経産省の役人と経団連の間で、残業代ゼロ政策についてどのような駆け引きがあったかということが赤裸々に語られており、中でも竹中平蔵氏の「アーティストは残業代ゼロなんですよ。」という発言が特に目を引く。アーティストと一般の雇われ労働者を同一視するというのは愚の骨頂としか言いようがない。 朝日新聞の記事によると、方向性は大幅に修正され、幹部候補だけが対象となったようだ。だが油断はならない。経団連は労働者から搾取しようと手ぐすねを引いて待ち構えているからだ。今日は残業代ゼロの何が問題なのかについて語りたいと思う。 成果？それとも時間？残業代ゼロの何が問題なのかについて、まず結論から言おう。一般的な雇われ労働者は、時間的に拘束されることがその職務の一部になっているからだ。 アーティストは確かに残業代は出ないかも知れない。しかし
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
漢(オトコ)のコンピュータ道
※この記事はMySQL Advent Calendar 2023の4日目です。 MySQL 8.0シリーズでは正式版になってから多数の新機能が追加されるというリリースモデルであった。正式版になってから追加された新機能の中に、GIPK（Generated Invisible Primary Key）というものがある。これはなんとMySQL 8.0.30で追加された機能だ。MySQL 8.0が正式版になってから、なんと4年と3ヶ月後のことである。そんな感じでMySQL 8.0の新機能は正式リリース後にも増え続け、途方もない規模になっている。このブログでは一度に紹介するのは諦め、少しずつ気の向いたものから紹介していこうと思う。今回はその第一弾として、GIPKについて解説しよう。
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
