A

这周我是早早决定不刻意做题，主要是上周的题其实没搞明白

这周又扫了一遍贪心算法，才发现其实自己还是审题不清，压根其实没太注意到最小的剔除数量

贪心算法参考

  • 参考1，自然是wiki了，不附
  • 参考2，有示例，讨论了贪心算法可能不是最优解，可能的证明推断最优解的方法？部分地方说的不像人话，其实就是示例题（背包）我也没看明白…但他确实刺激了我发现上周自己的问题
  • 参考3，整体比上篇说的更像人话，coin change变体增加20那个好像有个笔误吧，评论区

  • 参考4，其实没看完，主要被开篇第一句吸引

    后续

  • 参考更多，翻书，并且看动态规划

    R

    14.11 InnoDB Row Formats

    因为有译文，且看起来并不像机翻，所以尽量记录意会之笔记

    The row format of a table determines how its rows are physically stored, which in turn can affect the performance of queries and DML operations. As more rows fit into a single disk page, queries and index lookups can work faster, less cache memory is required in the buffer pool, and less I/O is required to write out updated values.

第一句还是翻了吧，算是预先给出一个原则性结论：表的行格式决定了它其中的行的物理存储形式，进而会影响到查询和DML操作的的性能；然后就说的很明白了，完全的预先的结论，单个磁盘page中（fit）更多的行，查询和索引检索就更快，内存消耗更少，（write out）更新数据时候消耗更少的IO

The data in each table is divided into pages. The pages that make up each table are arranged in a tree data structure called a B-tree index. Table data and secondary indexes both use this type of structure. The B-tree index that represents an entire table is known as the clustered index, which is organized according to the primary key columns. The nodes of a clustered index data structure contain the values of all columns in the row. The nodes of a secondary index structure contain the values of index columns and primary key columns.

（这段看着又有点像机翻了）

  • 表的数据存放在多个page当中
  • 这些page组织成B树索引结构
  • 表数据和二级索引都是B树存的
    • 表示整个表的那个B树索引是clustered index（应该就是所谓聚簇索引吧），是根据主键列进行组织的（也就是数据的物理顺序和主键顺序一致吧，就是通常认为的聚簇索引）
  • 聚簇索引数据结构节点包含行的所有列的值
  • 二级索引结构的节点包含索引列和主键列

其实这里面也没啥玩意儿，主要是强调了聚簇索引的顺序问题吧，这就是稍微有点玄的那个伪主键的选择问题

Variable-length columns are an exception to the rule that column values are stored in B-tree index nodes. Variable-length columns that are too long to fit on a B-tree page are stored on separately allocated disk pages called overflow pages. Such columns are referred to as off-page columns. The values of off-page columns are stored in singly-linked lists of overflow pages, with each such column having its own list of one or more overflow pages. Depending on column length, all or a prefix of variable-length column values are stored in the B-tree to avoid wasting storage and having to read a separate page.

主要就是说变长的列可能会存在其他的页里面，这里涉及细节不多…：

  • 其他的页，叫overflow pages（溢出页？）
  • 这些变长的存在外面的列，叫做off-page columns（页外列？）
  • 这些页外列的值存储在溢出页的 singly-linked lists，这…链表啊，linked list 在这个行当里面，就是查询复杂度On的那位先生
  • 而且每个列还都有它自己的一个或多个溢出页的list（应该是linkedlist吧）
  • 当然这个是存在其他的页里面还是直接存B-tree里面（应该是聚簇索引还是非聚簇索引都会有这种情况），是依赖于列的长度的

T

dedicated editor of Intellij

image.png

  • 如果打开另一个tab就叫专注？那就是专注吧
  • 其实还是万能提示快捷键Alt+Enter
  • 具得例子是正则，正则的这个tab叫做RegExp Fragment，但是感觉没什么直接的用途—— 除了在另一个tab里编辑
  • 真正有用的感觉是图里面的Check RegExp，在RegExp Fragment里面再使用Alt+Enter时候，跳出来的也是Check RegExp，这个弹出tip当中可以编辑正则，并敲个样例校验一下是否能匹配
  • Esc感觉真心关不掉RegExp Fragment那个editor，Check RegExp的tip是可以关掉的
  • synchronized是真的，tab和代码主体部分同时随敲击变化

  • escape字符的presented automatically能力如图image.png

    玩弄的概念

  • dedicated editor，前面已经嗯，算是吧反正

  • language injection，也许在另一个tab里面type，然后出现在代码正文里，这个就是injection吧…

  • escape character的presented automatic ，就是backslash在tab里面是正常的，但是代码行文中自动变成两个的意思吧

    man、info导读

  • 首先当然是自举了，man man，info info ，man info ，info man

    • info出来的有可能就是manual
  • 参考1，感觉写的挺全
  • 参考2，主要是从2往后的查询时候显示没有时候要安装，其他的好像也没写什么特别的
  • 参考3，info最重要的几个操作上的特点

  • 其他，从这里以及他的整站，感觉发现了一个有点意思的人

    mysql大字段问题一般性导读

  • 导读1，真的只是导读，这些QA中有些A很粗糙…大多有点粗糙

    • 里面也有大字段的问题，竟然还讲到了取舍，结果就没有价值倾向了
  • 导读2，就是排版…排版其实也不咋地，表格内都折行的厉害，也挺糙的，有些内容甚至自相矛盾，胜在覆盖面可以，用于自己以此当索引做自己的整理比较合适
    • 我都没印象里面有没有大字段
  • 导读3，说的大字段问题，往细了看很不像人话，但是大的分析方向是有说服力的——内存的利用率
  • 导读4，说的是行存储格式，记录的很细，搞得我都看不下去；文章好在没有过多的结论，就尽量给事实，不过麻烦也在这，其实还是得都看明白了才能得到点啥…
  • 导读5，也是说多了的时候就不像人话了，这个结论也是内存，命中率的问题，否则反正就得再扔回给磁盘再等，结论其实也挺清楚了

  • 导读6，MySQL 5.7的行格式文档，思量再三还是截部分当这周R部分得语料了

  • 参考1，是从这里answer中link到的，感觉stackoverflow没这个扩展更靠近我们自己在k8s 滚动更新方面的疑惑

    S

    临时换了两茬

    Redis的dbnum的用途

  • 简单地讲，应该是不用，或仅仅是测试用途

  • 稍微复杂一点来看，任何假设或基于此的设计都会在某些场景下失效，并且是有风险的
  • 某参考，文中比较令我震惊的是，竟然建议同一个实例存储不同环境的数据？我估计他意思是测试环境的实例，可以同时保有生产环境的数据吧