【自爆系列】浅谈我对数据库性能注意事项的错误了解
对与数据库的性能,有很多注意事项 入行这些年,以为积累了这些就够了,也以为这些是对的,其实多为表面现象,似似而非 1:不要用select *,因为这影响性能,但是人懒,没办法,用了那么多select *,也没见死机不是 2:where 后面的东西要走索引,所以经常玩
对与数据库的性能,有很多注意事项
入行这些年,以为积累了这些就够了,也以为这些是对的,其实多为表面现象,似似而非
1:不要用select *,因为这影响性能,但是人懒,没办法,用了那么多select *,也没见死机不是
2:where 后面的东西要走索引,所以经常玩命的建立索引,反复的看查询分析器,到底走索引了没,单纯为了走索引而走索引,以至于出现
nG数据2nG的索引
3:小子加with(nolock)了没,服务器死锁了!没加赶快加,但是难免犯懒,这个东西加没加也缺乏有效的检测,经常这个人忘了加,哪个人忘了加我怎么知道,哎说多了都是泪
4:sql服务器主要的性能指标为CPU,和链接数,直到后来,才知道这些只是表现,sql服务器的主要指标是io,其次是cpu和连接数
5:为了提高性能,写一个老复杂老长的sql,后来才知道,这个老复杂老长的sql表面上性能高了,实际上反而降低了,尤其是并发来的时候的时候
6:项目的开始,必然是以一个数据库开始了,里面放了所有需要的表。。。。。。
直到有一次打电话给运维dba
问,我们要提高数据库稳定性改咋整?
运维回复:你要做读写分离还是要做主从还是要做啥呢,啪啦啪啦啪啦啪啦啪啦啪啦啪啦,
最后根据你们服务器io的表现,建议啥也别做自己优化程序吧,当时就想吧第一个创建数据库的人,第一个创建表的人(虽然已经离职N年了)拉出来,问:你当初建表的时候咋就不考虑这些呢?
从运维的角度,提高数据库稳定性的基本手段只能是读写分离(确保写入数据没问题,保持数据流畅通,不掉链子),一主多从或多主多从
参考 这篇文章,
主从库之间是一种发布订阅的关系,发布者和订阅者之间并非实时同步的,通常会有几分钟的延时,更有甚者会有几个小时的延时。所以我们需要通过合理的使用来避开有延时这个问题。我们希望主库尽可能的少参与查询,来提高写的及时性;同时要让从库在不影响读出数据的准确及时的前提下尽可能的分担主库的压力
(PS:运维还说,做了主从或什么的,必须是整个数据库进行同步,而不是某几个表,同时,整个数据库表的结构的修改,新增或删除表有可能导致意外风险时同步失败等等啪啦啪啦啪啦啪啦)
从一个数据库变成多个一摸一样的数据库,是解决数据库稳定性
随之产生的问题就是延迟!!!!!!!!!!!!!!!!!!!!!
首先本人声明,本人还没做过基于mssql主从数据库上的程序,新浪sae的APP由于读写分离延迟太小忽略不计了,而且是mysql的
根据项目老大和运维dba的分析影响主从时候延迟的因素主要有
1:你这个主库写入的数据的速度快不快啊,如果快了,那就得把写的快的表和字段拆出去
2:你这个主库修改的速度快不快啊,如果快了,那就得把修改快的字段拆出去
3:你这个主库整体写入和修改的速度快不快啊,如果快了,那就得一分为二
4:你的这个查询啊,那些有group 等的都在那些表上,该拎出来的就拎出来
5:至于宽带、硬盘读写性能、cpu等我们都是无力改变的,就当做不知道吧
6:你们看着办吧
总而言之,言而总之,,以前我对sql的性能总停留在 索引上和select * 上,这其实是不科学的表面现象,至少走没走索引你监控不了那个查询造成ip或cpu高了
sql服务器可以监控的指标
1:io 是否满载,是否出现sina(x) 那样的波浪线,频繁的满载
ps:很多情况下,io频繁满载,例如周五,各个单位做数据汇总交差,管理员后来查询统计拉挂数据库服务器,进而拉挂前台展示站点。。。。
2:cpu是否满载,是否出现sina(x) 那样的波浪线,频繁的满载
cpu:说实话你有没有在sql里面写死循环,没写死循环cpu应该没事
3:连接数是否满载,是否出现sina(x) 那样的波浪线,频繁的满载
赶紧看看流量涨了没,是涨了多少,是以前的一倍还是2倍还是多少,如果少于3倍,问题必然出在1和2上
这3个要素也是运维或dba决定怎么搞数据库的主要指标,
话说基于主从结构的数据库改如何设计呢?
其实我也没设计过,最近我在折腾我自己的抓取站点,才第一次自己操刀给数据库分表,坑多路少。。。
根据运维和dba的意见(核心思想)----不管你做什么我们一年只给年干几次这样的操作!也就是主从设置什么的1年只设置几次,因为同步失败呀什么的就不管了。
根据我入行3年的个人经验整理如下(ps:这些均不考虑需要带锁的场景,我还没用过锁呢。。。。。)
1:以慢慢写为主的主库,例如博客园存放博文的表放的库,不可能出现1分钟1入100条数据的表
2:以快快读为主的读库,禁止使用各种锁,禁止使用各种表联合查询,禁止使用group等高io操作
3:以慢慢读为主的低并发库,例如各种要求时时查询(分钟级别),各种统计,各种查询
4:以快快写为主的库,这个库只作灾备切换处理,例如点击量统计、系统日志等
最后根据经过验,实现以上4点,没有搜索聚合数据这个工具是不行,刚开始了解lucene,了解的不多,欢迎高手拍砖。
最后就是关于orm
因为dba说,这个设置了,就不能随便新增表和修改表的结构了
随便应该是1小时改一次,不随便,应该是1各月弄一次,

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

目錄解決方法一解決方法二一、刪除Windows更新的臨時檔案二、修復受損的系統檔案三、檢視並修改登錄項目四、關閉網卡IPv6五、執行WindowsUpdateTroubleshootor工具進行修復六、關閉防火牆和其它相關的防毒軟體。七、關閉WidowsUpdate服務。解決方法三解決方法四華為電腦Windows更新出現「0x8024401c」報錯問題現象問題原因解決方案仍未解決?最近web伺服器因為系統漏洞需要更新,登入伺服器之後,更新提示錯誤碼0x8024401c解決方法一

小米15系列預計10月正式發布,其全系列代號已在外媒MiCode程式碼庫曝光。其中,旗艦級小米15Ultra代號為"Xuanyuan"(意為"軒轅"),此名源自中國神話中的黃帝,象徵尊貴。小米15的代號為"Dada",而小米15Pro則以"Haotian"(意為"昊天")為名。小米15SPro內部代號為"dijun",暗指《山海經》創世神帝俊。小米15Ultra系列涵蓋

不同Java框架的效能比較:RESTAPI請求處理:Vert.x最佳,請求速率達SpringBoot2倍,Dropwizard3倍。資料庫查詢:SpringBoot的HibernateORM優於Vert.x及Dropwizard的ORM。快取操作:Vert.x的Hazelcast客戶端優於SpringBoot及Dropwizard的快取機制。合適框架:根據應用需求選擇,Vert.x適用於高效能Web服務,SpringBoot適用於資料密集型應用,Dropwizard適用於微服務架構。

蘋果公司最新發布的iOS18、iPadOS18以及macOSSequoia系統為Photos應用程式增添了一項重要功能,旨在幫助用戶輕鬆恢復因各種原因遺失或損壞的照片和影片。這項新功能在Photos應用的"工具"部分引入了一個名為"已恢復"的相冊,當用戶設備中存在未納入其照片庫的圖片或影片時,該相冊將自動顯示。 "已恢復"相簿的出現為因資料庫損壞、相機應用未正確保存至照片庫或第三方應用管理照片庫時照片和視頻丟失提供了解決方案。使用者只需簡單幾步

自去年华为Mate60系列开售以来,我个人就一直将Mate60Pro作为主力机使用。在将近一年的时间里,华为Mate60Pro经过多次OTA升级,综合体验有了显著提升,给人一种常用常新的感觉。比如近期,华为Mate60系列就再度迎来了影像功能的重磅升级。首先是新增AI消除功能,可以智能消除路人、杂物并对空白部分进行自动补充;其次是主摄色准、长焦清晰度均有明显升级。考虑到现在是开学季,华为Mate60系列还推出了秋日礼遇活动:购机可享至高800元优惠,入手价低至4999元。常用常新的产品力加上超值

如何在PHP中使用MySQLi建立資料庫連線:包含MySQLi擴充(require_once)建立連線函數(functionconnect_to_db)呼叫連線函數($conn=connect_to_db())執行查詢($result=$conn->query())關閉連線( $conn->close())

PHP處理資料庫連線報錯,可以使用下列步驟:使用mysqli_connect_errno()取得錯誤代碼。使用mysqli_connect_error()取得錯誤訊息。透過擷取並記錄這些錯誤訊息,可以輕鬆識別並解決資料庫連接問題,確保應用程式的順暢運作。

優化C++多執行緒效能的有效技術包括:限制執行緒數量,避免爭用資源。使用輕量級互斥鎖,減少爭用。優化鎖的範圍,最小化等待時間。採用無鎖定資料結構,提高並發性。避免忙等,透過事件通知執行緒資源可用性。
