『mysqlで知っておくと便利な小技集～どちらかというと運用 - Qiita』へのコメントブックマークしました ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください Twitterで共有
［速報］Google Container Engine発表。Dockerコンテナを実行しKubernetesで管理するクラウドサービス
［速報］Google Container Engine発表。Dockerコンテナを実行しKubernetesで管理するクラウドサービス Googleは11月4日（日本時間5日）、サンフランシスコでイベント「Google Cloud Platform Live」を開催。Dockerコンテナ上でアプリケーションを実行し、それをKubernetesで管理するクラウドサービス、「Google Container Engine」（略称はGKE。Google Compute Engineの略称GCEとかぶるためにGKEになったのだと思われます）を発表しました。 これまでIaaS型のクラウドでアプリケーションを実行するには、仮想マシンのインスタンスを起動し、OSをインストールし、ネットワーク環境などを設定したうえでアプリケーションをインストールする、といった手順を踏む必要がありました。 Google C
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
MySQLでVisual Explain
MySQL Workbenchの次期バージョンである6.0のベータ版が公開された。例によってMySQLのダウンロードサイトで公開されているので、新機能が気になる人はゲットして試してみて頂きたい。見た目が若干今流行りのフラットデザインっぽくなってシャレオツ（笑）な感じに仕上がってる。 ベータ版が公開されたのを記念して、Workbenchに搭載されているナイスな機能について紹介したい。そう、Visual Explainだ。Visual Explainとは読んで字のごとく、SQLの実行計画を視覚的に表現したものだ。SQLが複雑になると、その実行計画は理解し辛いものとなる。 今日はVisual Explain基本的な使い方と、それがどのように見えるかを紹介しようと思う。 Visual Explainを使用するには、対象のMySQLのバージョンが5.6以上であり、なおかつWorkbenchのバージョ
知らぬはエンジニアの恥。今さら聞けない【コンテナ/仮想化技術】11選 - paiza times
Photo by Sam MacCutchan どうも後藤です！ もう10年以上になるでしょうか･･･ とにかくなんでもかんでも仮想化すればよいというこの風潮。paizaでも仮想化技術は大活躍中。インフラは仮想化技術の上に構築されているし、もちろんコードの評価環境だってばりばりの仮想環境上です。仮想環境ばっちこーい！ いったいいつからこんな流れになったんでしょう？どこに基準を求めるかでだいぶかわりますけれども、執筆現在から考えると、こうした流れには35年くらいの歴史があります。使われる仮想化技術は時代とともにかわってきました。だいたいどの時代にも流行ってものがありました。 最近（2014年ごろ）の流行とえば、インフラの一番下にハイパーバイザを入れて、その上でDockerを動かして、管理にはChefやPuppetを使うといったものです。数年経てば状況は変わるでしょうけれども、とにかく楽をした
開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
JDBC 8.1.7上でのNLS環境におけるキャラクタの整合性の問題について
［概要］ Java言語においては内部使用キャラクタコードとしてUnicodeが使われています。その為Oracle JDBCドライバは、キャラクタデータをデータベースに挿入する時、またデータベースからデータを取り出す時点で適宜キャラクタ変換を実行します。Java クライアントからJDBCを経由してOracleデータベースにデータを挿入する場合、JavaVMがクライアント側のネイティブコードからJavaのUnicodeの変換を行い、JDBCはデータベースもしくは自身のコード変換機能利用してUnicodeからOracleのデータベースキャラクタセットへの変換を行います。逆にデータを取り出す場合はその反対の事が行われます。 しかしながら、このコード変換の結果いくつかのコード情報が欠落したり、文字化けしてしまう事が有ります。これは、Oracle JDBCのバグでもJava VMのバグでもありません。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Test result