sqlserverデータ統計一

        Csdn 2010の優秀なブログの中には、データベースに関する文章があります。（csdnの駅構内で検索しても見つけられませんでした。幸いにこのブログの住所は保持されました。）、http://blog.csdn.net/yzsind/archive/2010/12/06/6059209.aspx、ここ数日はいくつかのデータベースの操作をして、操作手順を記録します。以下の操作は、データをできるだけ早く取り出す方法を考えるだけで、特定の環境で行われます。以下の操作はインデックス、量子クエリ、パーティションのいくつかの側面に関連します。
    
データベースは以前のシステムのsqlserverです。今回の操作は、表にmobile（218データ、9列）、service（149データ、12列）、チャンネル（42データ、12列）、Spinfo（21データ、8列）、service_log（service、mobile、url、accessudte、ipの5フィールド、約4千万件のデータは、月に500万件以上のデータがあります）。
ターゲットは統計が必要です。ロゴを月ごとに集計します。そして他の表から関連データを取り出す。作成文をエクスポートしました。添付ファイルに入れます。
    select count(*)from service_ロゴが遅く発見されました。20分以上かかります。では、似たようなsql：select…fromテーブル1、テーブル2…where……は書かなくてもいいです。
    インデックスを作成して、時間に対してインデックスを作成します。完成したら、性能が大幅に向上しました。1分ぐらいかかります。関連する前には間違いなく、時間帯でデータ量を縮小して、select…from service_log where access_date between'2010-05-01'and'2010-05-30'
    関連付けについて，まず標的量子クエリを用いて，標的量子クエリは性能を改善できないと結論した（少なくともSqlserver 2005はこのような）。ここでは標的量子クエリと標的量子クエリを使用していない2段のsqlを貼り付けますが、標的量子のsql読み取り可能性を利用した方がいいです。
 
標的量子クエリを使用していないsql:Select m.name，s.name，s.url，sp.name，num.n from dbo.service s，dbo.service_logs logs sl，(select count(*)as n，sl.service as id from dbo.servicesloggssssslelesssssshere sssssless.accessubetween'2011-02-01'and'2011-03-01'group byssmobile.sssbile，ssssssssssslelele，ssssssssssssssssssvile，ssssssslale，sssslale，sssslale.ssssssssssssvivivivivice，sssssssssn=num.id and s.sp=sp.id and m.did=sl.mobile
 
標準量子クエリを使用したsql:select(select name from dbo.mobile m.did=sl.mobile)as mobile，sl.service，s.name，s.url，s.url(select c.name from bo. chanel c.shhere c.ide=s.ccccccchanninininininine=s.ccccccc. id=s.id=s.com=s.com=s.cccchanenenenenenenenel)s.sssssssfrinenenenenel)s.sssssssfrishshshshshshshem==s.s，（select sl.service，sl.mobile as mobile，count（*）as num from dbo.servicess sl.access between'2011-02-01'and'2011-03'group by sl.mobile，sl.service WITH CUBE)as sl.id=sl.service
 
    索引には、集合インデックスと非集合インデックスがあります。この2つの違いは、ピンインと偏によって辞書で説明したほうが分かりやすいです。これを読むと、インデックスを集めたり、集めたりしないインデックスを知ることができるはずです。ここの時間には、インデックスを集めたり、インデックスを集めたりすることができます。インデックスを集めてみると、上のsqlの検索が1分で2秒になります。
   
   サーバーには約4000万のデータが2秒近くあり、現地のデータベースには一部のデータがあります。約1000万本のデータがあります。一秒未満の時間がかかります。さらに最適化すると、テーブルのパーティションを使って、sqlserverテーブルのパーティション操作ができます。このいくつかのブログは詳しく書かれています。http://blog.csdn.net/Sky_666/category/522973.aspx。また、既存のデータベースについては、統合インデックスを表のパーティションにすることができます。
   
   同時にキャッシュに合わせて最適化することができます。前に一つのプロジェクトをやってみました。すべてのベーステーブルをすべてキャッシュし、関連する操作に関連して、キャッシュのデータを直接呼び出して、表の関連付けをしません。ほとんどのデータベース操作は一つのテーブルに対してだけで、これによってコード量が大きくなります。ehcacheによってこの方面の仕事を処理することができます。しかし、実際には状況に応じて処理方法を選択する必要があります。このような数千万件のデータの操作は直接にsqlで操作すればいいです。