MySQLで全テーブルのレコード数を一覧表示する - Qiita
mysql> select table_name, table_rows from information_schema.TABLES where table_schema = 'zabbix'; +----------------------------+------------+ | table_name | table_rows | +----------------------------+------------+ | acknowledges | 15 | | actions | 33 | | alerts | 4104 | | application_discovery | 0 | | application_prototype | 0 | | application_template | 1109 | | applications | 1669 | | auditlog |
MySQL :: MySQL 8.0 リファレンスマニュアル :: B.3.2.8 パケットが大きすぎます
通信パケットは、MySQL サーバーに送信される単一の SQL ステートメント、クライアントに送信される単一行、またはソースレプリケーションサーバーからレプリカに送信されるバイナリログイベントです。 MySQL 8.0 Server およびクライアント間で転送可能なパケットの最大サイズは 1G バイトです。 MySQL クライアントまたは mysqld サーバーが max_allowed_packet バイトより大きいパケットを受け取ると、ER_NET_PACKET_TOO_LARGE エラーが発行され、接続が失われます。 一部のクライアントでは、パケットが大きすぎる場合、「クエリー中に MySQL サーバーへの接続が失われました」というエラーを受け取ることもあります。 クライアントとサーバーの両方にそれぞれ max_allowed_packet 変数があるため、大きなパケットを処理する場
rails console の中で、ただSQLをスッキリと直視したいだけのお話。 - Qiita
掲題の願望を満たすために、調べていましたら、学びがありましたので、「結論」と、 その**「過程からの学んだ4つのTIPS」**をお届けしたいと思います。 結論 explain 使う。なので、もう興味を失った方はもう以下お読み頂く必要はないかと思います。。 SQLをスッキリみたいというささやかな願望 rais c 使います。Active Record 使います。発行されるSQLを見たいです。 irb(main):001:0> User.first User Load (0.1ms) SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT 1 => #<User id: 1, name: "name1", created_at: "2016-10-08 11:20:08", updated_at: "2016-10-08 11
CockroachDB から覗く形式手法の世界 #CNDT2020 / CloudNative Days Tokyo 2020
CloudNative Days Tokyo 2020 で使用したスライドです。 バグのない分散システムの設計は果たして可能でしょうか？ この問いに対する一つの答えとして、CockroachDB では形式手法ツール TLA+ を用いて分散トランザクションの正しさを担保しています。 形式手法はシス…
LEFT JOIN / INNER JOIN を実行すると同じ内容のレコードが複数含まれる | iPentec
A.W.S (Another World Story) 新宿の路地裏にある小さな定食屋。木のカウンターに昼の光が斜めに差し込み、味噌汁の湯気が白く揺れている。 プログラマーの彩と DB エンジニアの健司は、揚げたてのアジフライ定食を前にノート PC を覗き込んでいた。 「健司さん、このクエリなんだけど」 彩は箸を止め、画面の一行を指差す。 SELECT * FROM orders o LEFT JOIN order_items i ON o.id = i.order_id 「同じ注文が何度も出てきて、売上が倍々ゲームになっちゃうの。原因がわからなくて」 健司は湯気越しに目を細める。 「orders と order_items は一対多だろ。JOIN した時点で明細の数だけ行が増える。それをそのまま集計したら、そりゃあアジフライが三枚四枚になるさ」 彩は衣のサクッという音を立てながら首をかし
【Ruby on Rails】重複しているレコードを取得する【MySQL】 - きゃまなかのブログ
概要 はじめに 重複しているレコードを取得 MySQL の場合 Ruby on Rails の場合 重複しているレコードを全て取得 MySQL の場合 Ruby on Rails の場合 おまけ 条件を満たさない重複レコードを削除する MySQL の場合 Ruby on Rails の場合 まとめ 概要 Ruby on Rails で DB から重複しているレコードを取得したい時がありました。 MySQL で重複しているレコードを取得する方法は分かるのですが、Ruby on Rails で同じ処理を書く場合、どうしたら良いのか分からなかったので調べて見ました。 MySQL で書く場合と、Ruby on Rails で書く場合の 2 パターン用意しています。 はじめに 今回利用するテーブルの中身を確認します。 ユーザ名 aaa が 3 件重複、bbb が 2 件重複、ccc が重複無しとなっ
mysqldumpでCouldn’t executeと言われた時の対策 – 塩焼きブログ
下記のようなmysqldumpコマンドを実行したところ mysqldump -h database -u hoge hoge2 -phoge3 --skip-lock-tables --default-character-set=utf8mb4 hoge4 hoge5 > ~/Downloads/hoge6.sql 下記のようなエラーが出た mysqldump: Couldn't execute 'SELECT COLUMN_NAME, JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"') FROM information_schema.COLUMN_STATISTICS WHERE SCHEMA_NAME = 'hoges' AND TABLE_NAME = 'item';': Unknown table 'COLUMN_S
イミュータブルデータモデル(世代編)
第1回 しょぼべん ( http://connpass.com/event/10849/ ) で話しした、イミュータブルデータモデル(世代編)です。
関心の分離を意識した名前設計で巨大クラスを爆殺する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をその
あなたが知らない リレーショナルモデル
Lua文化の伝承!? WFSにおけるイベントスクリプト活用術〜すべてはより良いコンテンツ制作のために〜
イミュータブルデータモデル(入門編)
ハンドノート T字形ERモデル セミナー資料 (Author; S.Toriyabe SYSTEMS DESIGN Co.,Ltd. Japan)
Amazon RDS - Qiita
6.メンテナンス## 新しいバージョンが出たときにMySQL を自動でアップグレードして自動で再起動してしまいます。 重要なウェブサイトやサービスで何の予告もなくデータベースに繋がらなくなったら大変ですので基本的に無効化しておきます。 参考：Amazon RDS DB インスタンスのメンテナンス 7.自動バックアップとスナップショット## その名の通り、自動でバックアップをしてくれる機能と手動でスナップショットをしてくれる機能がある。また、このスナップショットはリージョン間を移動することもできます。 なお、RDSのインスタンスを削除した際に、自動でスナップショットをとった場合は自動でスナップショットが削除されますが、手動でスナップショットを作成した場合は自分で削除する必要があります。 Single-AZ DB の場合は、スナップショット取得時はI/Oが短期間停止します。マルチ AZ DB
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
変更履歴を持つテーブルの設計 - Qiita
ある日のできごと 少し前、「ブログの記事のようなものを、履歴を残しつつ編集できるようにするにはどのようなテーブル設計が良いか？」と尋ねられたことがありました. その時, まず思いついた（というか見聞きしたことがある方法）のは以下の様な2通りの方法だった. 記事テーブルにバージョン番号を持たせる方法 記事テーブルとは別に, だいたい同じ構造の履歴テーブルを持つ方法 こられの手法のメリット・デメリットについて, すこし考えていきたいと思います. その1 記事テーブルにバージョン番号を持たせる方法 概要 この方法では, 記事テーブルは一つだけ用意し, 更新される度に新しいレコードを追加していきます. 主キーはidとなるが, これはサロゲートキーで, 本当の主キーは「記事グループid + verison」の複合主キーとなっています. 記事の最終更新日時は, 最新Versionのレコードのinser
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://tech.kurojica.com/archives/6291/
【MySQL】外部キー制約を一時的に無効にする - Qiita
GitHub - sue445/plant_erd: ERD exporter with PlantUML and mermaid format
MySQLのAUTO_INCREMENTについて色々と調べてみた。 - Qiita
MySQLで外部キーの制約があるテーブルをtruncateする方法 | ハックノート
MySQL 8.0.16 でテーブルスペース・REDO ログ／UNDO ログ・システムテーブル暗号化 - Qiita
