05-12学习总结

SQL调优

1.建立索引-索引可建立在经常使用where和orderby语句的字段上，建立索引提升了查询效率但降低了insert和update效率，因为跟新级插入时会重新建立索引

2合并sql-每次执行sql时会产生身份验证，连接及数据返回等操作

3调整where后的条件顺序-where语句后的条件按照至上而下的顺序执行，利用好顺序可减少查询时间，如优先过滤掉大量的数据

4用where替换having-

5减少使用事务begin translation-使用事务的begin translation时会将相关sql涉及的表锁定，导致其他查询阻塞

6不在索引上使用计算和函数-使用计算时会导致dbms放弃索引使用全量扫描

7优化select语句-避免查询不需要的数据，如select *

8优化update语句-在只更改非全部字段时，不要进行全部字段的更新，会导致大量log

9用nvachar/varchar替换nchar和char-前面两种格式在数据为null时不占用空间

10使用预编译-使用sql参数化来实现预编译可防止sql注入风险及提高效率

11用unionall替换union-在确认数据无重复情况下使用unionall，他不会进行数据排重及排序

12使用临时表暂存中间结果-避免对主表频繁扫描，提高了高并发状态下的性能，防止共享锁阻塞更新锁

13使用表别名-减少解析时间

14避免游标的使用-大数据时如超过一万行会出现游标，但是游标效率低

15优化删除语句-使用rowid

16优化插入语句-新建临时表数据量大时，应用select into 替换creattable，避免产生大量log。数据量不大时先creattable再insert

activemq

定义：是一个开源的，面向消息的，实现了jms1.1规范的中间件

作用：为系统间提供通信

优势：为系统提供了异步通信，实现系统功能调用的解耦。

原理：生产者将消息发送到activemq的服务端，服务端检查有多少消费者，将消息转发给消费者，此过程中，消费者接受消息后的一切操作与生产者无关，实现了异步通信。

两种通信方式

1-发布者和订阅者模式，此模式下游一个发布端，多个消费端，且发布者和消费者存在时间上的依赖，即消费者这能接收消费端创建后发布端发送的消息

2-p2p模式，点对点模式，该模式下只有一个消费者和一个发布者

如何解决消息丢失问题？-发布订阅模式下需要配置消息持久化配置，再订阅端设置一个消息id，发布端和消费端许需要配置消息持久化，配置以后，若消息没有被接收则将消息持久化到服务端知道消息被正确消费。

p2p模式下默认不会丢失

保证消息不被重复消费

1-消息不丢失

2-消息不重复执行 ：在业务端设置一个消息id表，每个被执行的消息保存在该表

redis数据类型

hash，set，string，list，sortedset，最基本的类型时string，他的key均以二进制保存