35 Matching Annotations
  1. Last 7 days
    1. 事务语句顺序优化

      对于一个事务,应该将更容易被多个事务访问的锁放在后面加,比如说店铺,而比如用户的锁则先加,这样能够减少店铺的锁占用的时间

    2. 死锁检测以及相应开销

      由于事务之间可能产生死锁,因此要么设置最大等待超时时间,要么设置死锁检测。

      死锁检测

      1. 维护等待图(Wait-for Graph)

      InnoDB 内部维护一个有向图,图中的节点表示事务(Transaction),边表示锁的等待关系。

      例如:事务A持有行X的锁,事务B请求行X的锁并被阻塞,则图中有一条边从B指向A(B→A,表示B在等待A释放锁)。

      当某个事务请求锁时,如果锁已被其他事务持有,InnoDB 会更新等待图,添加一条新的边。

      2. 检测环(Cycle)

      每次有事务请求锁失败(进入等待状态)时,InnoDB 会触发死锁检测。

      深度优先搜索(DFS):InnoDB 通过DFS遍历等待图,检查是否存在环。如果发现环,则判定为死锁。

      优化:为了减少性能开销,InnoDB 不会每次都全图遍历,而是从新加入的边出发,仅检查可能形成环的路径。

      3. 选择牺牲者(Victim)

      如果检测到死锁,InnoDB 会选择一个事务作为牺牲者(通常选择回滚成本更低的事务,例如修改数据量较小的事务),强制回滚该事务,并释放其持有的锁。

      回滚后,等待图中对应的边被移除,其他被阻塞的事务可以继续执行。

      死锁的开销

      问题

      因此由于事务的不断加入,图会变得越来越大,进行环检测是O(n)的操作,若n很大则cpu大量消耗。

      解决

      可以通过中间件对操作相同key的事务限流,这样事务虽然也在等待,但是没有增加死锁检测的负担。

    1. 这个跟索引c的数据是一模一样的。

      当索引值相同时,按照主键排序,因此索引最后的字段是主键的话,可以去掉该索引

    1. 如果有不合适的,为什么,更好的方法是什么?

      重建主键

      删除主键相当于重建整个表,mysql内部会使用一个隐式的自增字段存储记录。而创建主键则再次进行更改,将其从隐式转成显示的字段。因此如果需要重建主键索引则可以直接使用alter table T engine=InnoDB。

      删除自增主键

      如果要删除自增主键,那么主键列必须将自增删除掉,因为隐式的主键也是自增的,一个表只能有一个自增字段

    2. 显然,主键长度越小,普通索引的叶子节点就越小,普通索引占用的空间也就越小。

      尽量使用自增主键,能够避免页分裂,同时减少普通索引叶子节点的占用空间

    1. 覆盖索引、前缀索引、索引下推

      索引主要优化手段。尽量避免回表从而提高查询性能

  2. Apr 2024
    1. 假设x为n维向量,在微分多元函数时经常使用以下规则: 对于所有A∈Rm×n,都有∇xAx=A⊤ 对于所有A∈Rn×m,都有∇xx⊤A=A 对于所有A∈Rn×n,都有∇xx⊤Ax=(A+A⊤)x ∇x‖x‖2=∇xx⊤x=2x 同样,对于任何矩阵X,都有∇X‖X‖F2=2X。 正如我们之后将看到的,梯度对于设计深度学习中的优化算法有很大用处。
  3. Dec 2022
  4. Aug 2022
    1. 底层通信协议支持选择 KCP 协议

      kcp优化

    2. 避免了等待与后端服务建立连接以及 frpc 和 frps 之间传递控制信息的时间。

      连接池优化

  5. Mar 2022
    1. 不幸的是,它被误解扭曲了。许多软件工程师将这一准则理解成"你永远不应该优化代码!",认为没有必要进行优化。 Tony Hoare 和 Donald Knuth 的真正意思是,代码微优化(例如,一条特定语句消耗多少 CPU 周期)之前,开发者应该担心其他问题。而且,原话并不是说:"在开发的早期阶段,关注程序的性能是有害的。" 他只是反对过早的优化。 以下几点理由,可以解释为什么不能忽视软件性能。程序员正确的做法应该是,在软件开发的早期阶段,就关注性能问题。 (1)性能问题不容易在软件开发的最后阶段解决。20%的代码占用了80%执行时间,它们可能散布在整个源代码中,不容易一次性修改解决。 (2)许多工程师相信,到软件发布时,CPU 的性能将会提高,以弥补部分代码的性能低下。尽管在1990年代确实如此,但在最近十年 CPU 性能非常有限。 (3)软件工程师认为,他们的时间比 CPU 时间更有价值。因此,浪费 CPU 周期以减少开发时间是对的。但是,他们忘记了,用户的时间比他们的时间更有价值。 (4)优化可能会导致产品延迟进入市场,并降低利润,这是正确的。但这种想法忽略了性能不佳的产品可能很难销售,尤其是在市场竞争激烈的情况下。 (5)有些程序员认为,几乎没有必要确保在软件的设计阶段,就使用最佳算法,先实现功能再说,因为以后总是可以替换更好的算法。所以,无需担心软件在开发阶段的性能,以后可以通过更好的算法对其进行提高。不幸的是,更好的算法在后期不一定可以实现,而且代码往往因为牵扯太多,无法轻易替换其中某个部分。

      过早优化的谬误

      优化是一个平衡

    1. 由图中可看到,每种设备都有两个指标: - 延时(响应时间):表示硬件的突发处理能力; - 带宽(吞吐量):代表硬件持续处理的能力。

    2. 大多数情况,性能最慢的设备会是瓶颈点。

      如,下载时网络速度可能会是瓶颈点,本地复制文件时硬盘可能是瓶颈点。

      为什么这些一般的工作能快速确认瓶颈点呢?

      因为我们队这些慢速设备的性能数据有一些基本的认识,如网络带宽是 2 Mbps,硬盘是每分钟 7200 转等等。

      (结论)因此,为了快速找到 SQL 的性能瓶颈点,需要了解计算机系统的硬件基本性能指标,如当前主流计算机性能指标数据。

    3. 数据库访问优化法则

      (目的):要正确的优化 SQL;

      (条件):需要快速定位性能的瓶颈点;

      (进一步阐释说明):即是快速找到 SQL 主要的开销在哪里?

    1. let msg = res.code != 0 ? res.msg || '操作失败' : res.msg || "操作成功";

      代码优化,可读性的衡量:

      let options = res.code != 0 ? { msg: '操作失败', icon: 2} : {msg: "操作成功", icon: 1};

      msg = res.msg || options.msg;