まで程遠いが、これから新しい機能を試してみたいとかボラクルに取って代わり
低コストで次世代データベース開発のために利用したいエンジニアは今こいう時だから
こそver.5.0に着目したいところだ。
5系がまだアルファ段階だからといって敬遠するの良いが、テストマシン上で独自に開発を
して、テストマシン等で実運用するのも一つの道であろう。
開発の成果は、MySQLやOpenBSDに随時報告することが重要だ。
ネットの情報かなり試したんだけど、5.0までと違うのか、まったくダメ。
5.1で同じような状況になった方はいませんか？
「商品一覧テーブル(product)」と「商品カテゴリテーブル(category)」があり、
product.category_cd = category.category_cdを他：1で結びつけています。
「商品カテゴリテーブル」にはカテゴリ名カラムがあり、
商品検索のときに商品名とカテゴリ名両方検索できるようにしたいと思っています。
すでに構築されたプログラムの改変のため、JOINが非常にし辛いソースとなっていて、
ビューを使うとコストが抑えられると思っているのですが、遅いと聞くので使用していいか戸惑っております。
商品の修正もそこそこありで、検索もそこそこ使うといった感じです。
この場合、ビューを使ってよいものでしょうか。
VIEWの内容をSELECT文の中に展開して書き込むかで
実行計画が変わることがある。
どちらが速いかはケースバイケース。
ただ のパターンではその前に
双方のcategory_cd列にINDEXが作ってあるかどうかが重要。
まずINDEXがあることを確認した上で、
VIEWのありなしで検証してみるのをオススメする。
オライリーのMySQLクイックリファレンスを見れ
C APIについても載ってる
ttp://www.itmedia.co.jp/news/articles/1109/27/news027.html WebブラウザやFlash、Javaなどのプラグインの脆弱性を突いてインストールされ、ユーザーが
クリックなどの操作をしなくても、MySQL.comのWebサイトを見ただけで知らないうちに感染する
恐れがある。
開始押したらすぐに停止する
解決策わかる人いる？
なんかのエラーで停止してるんじゃない
ログみてみたら
・実行速度
・使用メモリ量
において、どのくらい違うものでしょうか。
なにか資料へのポインタでも頂けたらと思います。
なおOSはDebian Linuxです。
期待する解答例
・経験則で言うと、メモリ消費量は64-bit版の方が20%多い
・intのサイズが異なるので、intのカラムが多いとメモリ消費量が多くなるが、charだと変わらない
・実行速度は64bit版のほうが速いはずだが、ぶっちゃけSQLのチューニングのほうがよっぽど大事だから気にすることはない
バッファ上はMySQLのデータ型の分しか消費しないから、32bit、64bitで変わらない。
ていうかintはx86_64でも4バイトじゃね。
実行速度はCPUによる。
例えばCore 2のときは64bit動作でMacro-OPs Fusionという機能が効かなくて
あまり速くなかった。Nehalem以降は64bitの方が速いと思う。
実際の性能はデータをメモリ上にどれだけキャッシュするかが勝負なので、
32bitだと仮想メモリ4GBの壁があるので64bitの方が断然有利。
>バッファ上はMySQLのデータ型の分しか消費しないから、32bit、64bitで変わらない。
なるほど。メモリ消費量に違いはない（あったとしてもわずか）ということですか。
>実行速度はCPUによる。
>例えばCore 2のときは64bit動作でMacro-OPs Fusionという機能が効かなくて
>あまり速くなかった。Nehalem以降は64bitの方が速いと思う。
それは知りませんでした。
x86_64のほうがレジスタ数が増えた分、速いと思ったのですが、必ずしもそうではないんですね。
Nehalemというのは、Core2DuoではなくCore i3とかi5とかいうやつですね。
じゃあサーバのCPUの種類を調べてみる必要がありますね。
>実際の性能はデータをメモリ上にどれだけキャッシュするかが勝負なので、
>32bitだと仮想メモリ4GBの壁があるので64bitの方が断然有利。
使ってるのが安いVPSなので、そこまでメモリを利用できません。
たいへん参考になりました。ありがとうございました。
JavaからMySQLへアクセスし郵便番号検索する仕組みになっているのですが、
まれに「NullPointerException」がでて原因が追究できず困っています。
郵便番号を入力するテキストボックスがあり、
横にある「郵便番号検索」のボタンをクリックすると
入力された郵便番号に相当する住所が住所のテキストボックスに表示されます。
どなたか何か原因として考えられること教えていただけませんか？
(環境)
Java Version: 1.6
MySQL: 5.0.77
OS: CentOS 5.3
百個や二百個じゃ済まないだろ
まずは例外発生時のスタックダンプを晒してみろ。
テーブルの中身をエクセルみたいに表示してちょこっと編集
・・・とかがさっさとできたらいいんだけど。
phpmyadminじゃできないですよね？ できたらwebベースじゃないほうがいいです。
今フリーバージョンは出てないけどw
あー、今、それ見てました！
Lite無くなってる(´･ω･`)ｼｮﾎﾞｰﾝ
有料だけどaccessでODBC接続とかが無難なんでしょうか？
使ったことは無いけど
Workbenchとか？後は知らん
workbench
商用じゃないほう（Community エディション？）はフリーなんでしょうか？
個人事業で使う場合は商用？
機能が足りててサポートいらないならそのまま仕事で使って問題ないよ。
確実にお金を払う必要などない人間。
金を払わにゃならんようなやつは、聞かずともわかるようになっている。
あんたのようなことを言うやつも金を払う必要はない。
もちろん、サポートしてほしいなら話は別だ。
必要がない。じゃなくて黙認されている、じゃねぇの？
ttp://www.softagency.co.jp/products/mysql/license/ の上から四行目の選択肢あたりは社内システムでも問題になりうると思うが。
ttp://http://d.hatena.ne.jp/uehaj/20100710/1278772393 ttp://http://www.nicovideo.jp/watch/sm16819087 これ凄すぎｗ
インストール後の設定ウィザードでサービスの起動がうまくいきません
応答なしになりますなぜだ
また、conn から curを作成できる理由って何でしょうか？
↓
告訴状を【検察の直告班】に郵便局の内容証明付で送付（疎明資料・証拠にはＩＣレコーダー、スマホによる録音が適しています）
↓
審査 → 不受理 → 告訴状再提出または刑法 第193条で訴えを起こす
↓
受理 → 告訴事実を認め示談交渉（↓） →示談成立 → 法廷相場50〜100万円の示談金 ※示談拒否が良い
↓ ↓
事案化← 前科あり ←示談不成立（↓）→ 示談外交渉→ 犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓ ↓
↓ 起訴 →公判 → 罰金刑＝前科（起訴事実を認めてるため）→追討ち民事訴訟
↓
審査 → 起訴（強制捜査・留置場）→ 公判 → 懲役刑などの厳罰（反省が認められないため）→追討ち民事訴訟
↓
不起訴、起訴猶予
↓
検察審査会法第３０条（検察審査会へ申し立て）→ 起訴 → 起訴後は同上
刑法 第193条（公務員職権濫用）で検察事務官を刑事告訴 → 同上
◎告訴→告訴受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約（公正証書・即決和解で秘密保持契約）
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者に告訴できます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事告発（刑事訴訟法239条1項）も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。
注意：告訴が受理されない理由
●３年間（※）の時効が過ぎたもの ※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの ※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。
人事原則
１ 現行法では、社員が仕事を怠けたり、能力不足、就業規則違反、目標を達成できなくても解雇をしたり叱責することは違法です。どんな駄目社員、嘘つき社員、怠け者も定年まで解雇が違法なのが現行の正社員制度です。
２ パワハラは社風にあわない社員、成績の振るわない社員を自主退職に追い込む言わば人事的措置として用いられることが多い。
※違法な解雇の和解金相場は、労働審判で３ヶ月、通常裁判で１年以上の報酬、さらに社員が和解を拒めば復職が可能です。弁護士への着手金は12〜15万円＋20%の和解金、和解拒否なら20〜50万円程度。
人事部・ホットライン・御用組合へ直訴
メリット： 一時的緩和や人事異動
デメリット： 役員へ情報筒抜け、危険分子の烙印（情報漏洩がホットライン直訴者に多いのは人事部の常識）、パワハラ放置で自主退職に追い込まれる
民事訴訟・調停・労働審判
メリット： 損害賠償
デメリット： 裁判費用、解雇措置、民事不介入で刑事事案化を阻止、長期係争、パワハラ上司の継続雇用
刑事告訴
メリット： １パワハラ上司の解雇・懲戒、または２多額の和解金、１と２どちらでも被害者の雇用は維持
デメリット： 人事異動（出世コースから外れる）
◎録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
◎告訴受理後の和解金は加害者の資産・収入に応じて変えてください。犯罪者の昨年の年収の半額程度×最大懲役年数が妥当です。
◎パワハラの被害についての告訴は１侮辱罪２脅迫罪３強要罪４威力業務妨害罪５傷害罪の順序で行ってください。警察・検察の協力（犯罪者の自宅・職場の強制捜査、留置所勾留）により罪の立証が楽になります。
◎刑事告訴した社員を解雇したり処遇面で著しい差別を行うことはないでしょうが、出世や管理職以上の昇進の可能性はあきらめるべきでしょう。
◎刑事告訴は民事訴訟と違って裁判による被害者への2次被害にありません。検察庁が被害者に代わって訴えをおこすので、無料で、時間と手間も告訴状をかくことと音声録音を残すだけです。
◎和解契約（公正証書・即決和解）では告訴した事実は秘匿事項となります。犯罪者が秘密保持契約を違反した場合の損害賠償金は、最低5000万円〜にしましょう。
機器が故障したため、Atom-D2700(3GB)に入れ替えをしました。予算があまり無かったのです。
・クライアントは10台程度。
・innodbのみ使用。
・一覧表示を多用している。ページング処理をする為、countでレコード総数を取得している。
・my.cnfはそのまま流用している。
切替直後から、「一覧表の表示が遅い」というクレームが後を絶ちません。
以前は瞬時にページの切替ができましたが、切替後は数秒から30秒程度の
待ち時間が発生しています。
利用者からは、物凄い剣幕で「遅せーんだよ、なんとかしろ！」といわれていますが、
「慣れればいいだろ」とも言えず、解決策を模索中です。
CPUの処理性能が、これ程影響してくるとは思いませんでした。
インデックスを工夫する
この程度しか思いつかないｗ
countが劇遅で、だけど多用せざるを得ない要件なら、countだけを保存するテーブルを作って、
insert/deleteトリガーでcountをプラマイするようにして、それをページ処理するときに参照する
仕組みにすれば？
ご回答ありがとうございます。
ご意見を参考に、色々と試して見ます。
phpMyAdminを使ってデータベースのエクスポートしたのですが、外部キー制約がエクスポートできません。
外部キー制約も含めてエクスポートするにはどうしたらいいですか？
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
まだメモリに載ってないとか
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
MG7LSJ6659
