MySQL 8.0のGROUPING関数(MySQL Server Blogより) | Yakst
MySQL 8.0.1から追加されたGROUPING関数に関するMySQL Server Blogの記事を紹介します。 免責事項 この記事はChaithra Gopalareddy氏によるMySQL Server Blogの投稿「MySQL 8.0: GROUPING function」(2017/5/2)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0.1からサーバーがSQLのGROUPING関数をサポートするようになりました。GROUP関数は、(ROLLUP操作によって生成される)超集約行(super-aggregate row)のすべての値を表すNULLであるか、通常行のNULLかを区別して利用できます。 はじめに MySQLサーバーはGROUP BY拡張のROLLUPをしばらくサポートしてきました。ここにGROUP BYでROLLUPを利用す
MySQL 8.0.1でutf8mb4_ja_0900_as_csが導入された
Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0 | MySQL Server Blog （ユーザーによる日本語訳: 寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst）で言及されていた日本語用の照合順序 utf8mb4_ja_0900_as_cs 。 mysql80> SHOW COLLATION LIKE 'utf8%ja%'; +-----------------------+---------+-----+---------+----------+---------+ | Collation | Charset | Id | Default | Compiled | Sortlen | +-----------------------+-
PDOに複文実行を禁止するオプションが追加されていた
エグゼクティブサマリ PHP 5.5.21、PHP 5.6.5 以降、PHPにPDO::MYSQL_ATTR_MULTI_STATEMENTSというオプションが追加され、PDO+MySQLの組み合わせで、SQLの複文を禁止できるようになった。この設定はSQLインジェクションの緩和策として有効である。 はじめに 2013年12月に公開した PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能 にて、PDOとMySQLの組み合わせで、SQLインジェクションの文脈で複文呼び出しが可能であることを報告していましたが、その後のPHPのバージョンアップで、複文実行を禁止するオプションが追加されていましたので報告します。 対象のバージョンは以下の通りです。 PHP 5.5.21 以降 PHP 5.6.5 以降 全ての PHP 7.0、7.1 前述の記事を書いた後、3大
MySQLによるJSONデータ型処理 – variable.jp [データベース,パフォーマンス,運用]
MySQL5.7において、JSON(JavaScript Object Notation)がサポートされていて、 様々な言語やアプリ間で、より簡単にデータの受け渡しが行えるようになりました。 ドキュメントをJSONフォーマットでデータベースに保存して、 様々なアプリケーションから呼び出して利用出来るなど、 汎用性と運用面での活用が出来るようになっています。 1) ネイティブのJSONデータ型 効率的なデータ処理と保管にネイティブ内部バイナリ形式をサポート。 2) 組み込みJSONファンクション 効率よくドキュメントを保存,検索,更新,操作する事を可能にします。 3) JSON コンパレーター 文書データを容易にSQLクエリと統合することが可能 4) Generated Columnsを利用し、ドキュメントにインデックスを利用する事が可能。 新しいアナライザーは,自動的に利用可能で最適な機能
MySQLインデックスのお手入れの基本 | Yakst
Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基本的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか？順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを
MySQL で utf8 と utf8mb4 の混在で起きること - tmtms のメモ
MySQL を UTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。 MySQL の UTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。 UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。 utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。 登録 接続が utf8mb4 でカラムが utf8mb4 あたりまえですが、そのまま登録されます。 mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺'); mysql> select * from utf8mb4; +--------
MySQL Shell / X DevAPI / X Protocol - @tmtms のメモ
MySQL 5.7.12 で突如登場した MySQL Shell とか X DevAPI とか X Protocol とかが面白そうだったので調べてみました。 Document Store とかも同じ文脈で語られてて、それぞれの用語が何を表してるのかややこしかったので、まずその辺から。 X Protocol mysqlx プラグインを使用することで追加されるサーバー/クライアントプロトコル。ポート番号は 33060。 詳細→ https://dev.mysql.com/doc/internals/en/x-protocol.html X DevAPI 各プログラミング言語用の新しいAPI。Document Store用のAPIも含む。今のところ、MySQL Shell JavaScript, MySQL Shell Python, Java, .Net, Node.js 用の API があ
PDOのサンプルで数値をバインドする際にintにキャストしている理由
先日PHPカンファレンス北海道2016にて「『例えば、PHPを避ける』以降PHPはどれだけ安全になったか」と題して基調講演を担当致しました。その際のスライドはこちら。 そうしたところ、以下のご指摘をいただきました。 @ockeghem スライド拝見しました。39番目のスライドですが、バインドのタイミングでintにキャストするのはちょっと例として良くない気がします。意図的にオーバーフローを起こすことで想定外のレコードの取得を許してしまいそうです。キャストしない方がまだ安全だと思うのですが。 SQLデータベースは、int型よりも大きな桁数を扱える場合があるので、intへのキャストを避けた方がよいという指摘は一般論としてはもっともなものだと考えます。PHPの場合、9223372036854775807を越える数字文字列をint型にキャストすると、9223372036854775807が返ります(
mycli
mycli BlackLivesMatter We value the diversity of our community. We strive to amplify the voices of the oppressed to eradicate racism and xenophobia. We ask our community to stand together in support of the Black community. MyCLI is a command line interface for MySQL, MariaDB, and Percona with auto-completion and syntax highlighting. Source: https://github.com/dbcli/mycli Bug tracker: https://githu
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！）
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！） 【2016/01/13 10:12】 MySQL 5.7.11でdefault_password_lifetimeのデフォルトは0に変更になりました！ それ以降のバージョンであればこの記事の内容は気にする必要はありません。 日々の覚書: MySQL 5.7.11でdefault_password_lifetimeのデフォルトが0になるらしい！ TL;DR default_password_lifetime= 0 を秘伝のmy.cnfに入れておくつもり。 MySQL :: MySQL 5.7 Reference Manual :: 5.1.4 Server System Variables パラメーターの意味は読んで字のごとく、「最後にパスワードが更新さ
MySQL 5.7の罠があなたを狙っている
2015/08/22 YAPC::Asia Tokyo 2015 Lightning Talk 2016/01/13 update about default_password_lifetime will be 0
MySQL と寿司ビール問題 - かみぽわーる
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
InnoDBの制限とファイルフォーマットAntelopeとBarracudaの違い - かみぽわーる
この投稿はMySQL Casual Advent Calendar 2014の5日目の記事です。 @kamipo 質問させてください。このエントリーで COMPRESSED ではなく DYNAMIC を選んでいる理由はなぜですか？あまりDB詳しくないので参考リンクなどポインタを教えていただけるだけでも構いません http://t.co/9sC4lzLjXr— kiyoshi nomo (@kysnm) November 27, 2014 先週ツイッターでInnoDBのことを質問されまして、せっかくなのでアドカレのネタにしようと思いますってことでInnoDBのファイルフォーマット毎の違いをカジュアルに説明しようと思います。 InnoDBのファイルフォーマットBarracudaと新機能 InnoDBにはファイルフォーマットとして昔からあるAntelopeと新しいフォーマット(5年も前からあるの
MySQL の照合順序の命名規則 - Qiita
MySQL の照合順序って難しいですよね。 使いこなすと便利そうだけれども。 照合順序に関するおさらいとか。 そもそも照合順序って "照合順序"とは、MySQL （に限らないけど）が文字を比較するときの基準・規則です。"Collation" という英単語からきています。「照合順序」という和訳からはわかりにくいのですが、「照合（等しいか等しくないか）と順序（順番が前か後か）を比較する際のルール」です。「＞」「＝」「＜」のどれかということですね。 例えば、SQL文で次の比較文はどう評価されるでしょうか？ プログラミングとかを少しやっていると、 False が返される気がしてきますが、MySQLは「照合順序」によって True も False も返却しうります。 具体的には照合順序が "unicode_general_ci"`（バイト列をユニコードとして読み取り_通常規則で照合_ただし大文字小文
Homebrewで入れたmysqlを再起動するにはLaunchAgentのKeepAliveをfalseに設定しておく - There's an echo in my head
~/Library/LaunchAgents/homebrew.mxcl.mysql.plistのKeepAliveがtrueになっていると、mysqlのプロセスが止まった時点でlaunchctlが頑張って起動しなおそうとする。 このため、mysqlを手動で再起動しようとmysql.server restartを叩くと、この機能と衝突してしまってうまくいかない。stop/startもだいたいダメ。とはいえ再起動のたびにplistをunload/loadするのも面倒くさい（今までこれをやってた）。 じゃあどうするのかというと、KeepAliveをfalseにする。 $ diff -u ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist{.org,} --- ~/Library/LaunchAgents/homebrew.mxcl.mysql.pl
Starting and stopping background services with Homebrew
editor’s note (August 4, 2023): New versions of MacOS and homebrew means the information in this article is no longer current. If you are on a version of MacOS Ventura or later, see this post for further information. If your version of MacOS is pre-Ventura…read on! I love Homebrew, but sometimes it really gets me down, you know? Especially when I have to deal with launchctl. launchctl loads and un
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL(InnoDB) で charset を utf8mb4 にする注意点の現在 - Qiita
Fooling around with MySQL JSON full-text indexing |
GitHub - go-sql-driver/mysql: Go MySQL Driver is a MySQL driver for Go's (golang) database/sql package
