推荐星级:
  • 1
  • 2
  • 3
  • 4
  • 5

高性能 高并发 分布式数据库架构

更新时间:2020-12-28 07:48:31 大小:8M 上传用户:sun2152查看TA发布的资源 标签:数据库 下载积分:2分 评价赚积分 (如何评价?) 打赏 收藏 评论(0) 举报

资料介绍

1模糊搜索(like语句)

2数据缓存(mecache,redis

3QL语句优化(提高SQL运行效率

4.存贮过程(服务端运行,减少网络传输批处理执行,提高效率)

5表结构设计优化(字段冗余避免关联查询;nu优化,字段类型优化 tinyint> int'char> varchar)

6查询索引7物化视图

8表分区

分流(数据,日志,索引)

1查询的模糊匹配

尽量避免在一个复杂查询里面使用LIKE%parm12.索引问题

在做性能跟踪分析过程中,经常发现有不少后台程序的性能问题是因为缺少合适索引造成的,有些表甚至一个索引都没有。这种情况往往都是因为在设计表时,没去定义索引,而开发初期,由于表记录很少,索引创建与否可能对性能没啥影响,开发人员因此也未多加重视。然一旦程序发布到生产环境,随着时间的推移,表记录越来越多这时缺少索引,对性能的影响便会越来越大了这个问题需要数据库设计人员和开发人员共同关注法则:不要在建立的索引的数据列上进行下列操作:

◆避免对索引字段进行计算操作

◆避免在索引字段上使用not,<>,!=

◆避免在索引列上使用 IS NULL和 S NOT NULL

◆避免在索引列上出现数据类型转换

◆避免在索引字段上使用函数

◆避免建立索引的列中使用空值

◆ where语句abc。

3在可以使用 UNION ALL的语句里,使用了 UNION UNION因为会将各查询子集的记录做比较,故比起 UNION ALL,通常速度都会慢上许多。一般来说,如果使用 UNION ALL能满足要求的话,务必使用 UNION ALL。还有一种情况大家可能会忽略掉,就是虽然要求几个子集的并集需要过滤掉重复记录,但由于脚本的特殊性,不可能存在重复记录,这时便应该使用 UNION ALL,如xx模块的某个查询程序就曾经存在这种情况,见,由于语句的特殊性,在这个脚本中几个子集的记录绝对不可能重复,故可以改用 UNION ALL)

4避免在 WHERE子句中使用in,not in,or或者 having可以使用 exist和 not exist代替in和 not in可以使用表链接代替 exist。Having可以用 where代替,如果无法代替可以分两步处理


部分文件列表

文件名 大小
高性能,高并发,分布式数据库架构.pdf 8M

【关注B站账户领20积分】

全部评论(0)

暂无评论

上传资源 上传优质资源有赏金

  • 打赏
  • 30日榜单

推荐下载