karr's blog

使用CSS的scroll-behaviorscroll-behavior: auto | smooth | inherit | unset 一般我们使用auto和smooth就可以了，smooth表示滚动很平滑，有过渡效果，auto没有过渡效果，一闪而过。 我们一般回到顶部的话把这个属性设置在html上即可。代码如下 只使用 html a 标签实现12345678910111213<div id="container" class="box"> <p>Hello, Backtotop</p> <br/> <p>Hello, Backtotop</p> <br/> <p>Hello, Backtotop</p> <br/> <p>Hello, Backtotop</p> <br/> /* 省略部分代码 */</div><a ...

mysql limit 使用方法在我们使用查询语句的时候，经常要返回前几条或者中间某几行数据，这个时候怎么办呢？不用担心，mysql已经为我们提供了这样一个功能。 1SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset MySQL Limit 优化解决方案性能到底能有多高？MySql 这个数据库绝对是适合dba级的高手去玩的，一般做一点1万篇新闻的小型系统怎么写都可以。可是数据量到了10万，百万至千万，他的性能还能那么高吗？一点小小的失误，可能造成整个系统的改写，甚至更本系统无法正常运行！好了，不那么多废话了。用事实说话，看例子 数据表 collect ( id, title ,info ,vtype) 就这4个字段，其中 title 用定长，info 用 text, id是逐渐，vtype 是 tinyint，vtype 是索引。这是一个基本的新闻系统的简单模型。现在往里面填充数据，填充10万篇新闻。最后 collect 为 10万条记录，数据库表占用硬盘1.6G。 OK ,看下面这条sql语句 12sele ...

github向服务器commit时，若有大于100MB的文件会commit失败，同时报错提示。若要将大文件顺利提交，可以通过以下步骤。 如果版本库已经执行了commit、push操作，记录中已经有了大文件，那么需要先把大文件从版本库记录中删除 1，删除错误缓存索引 对于文件： 1git rm --cached path_of_the_file 对于文件夹: 1git rm --cached -r path_of_the_dir 2，重新提交 修改提交信息：git commit --amend 重新提交：git push origin master 这样就把所有小文件都提交到远程仓库了 使用Git Large File Storage进行大文件提交 1，安装教程：https://github.com/git-lfs/git-lfs/wiki/Installation 2，查找大文件，并把大文件加入大文件track中 查找大文件：find ./ -size +100M 把上述查找到的大文件通过 git lfs track "path_of_the_file&quo ...

借助lambda filter 12345678def foo(a, b, c): return a < b and b < cmyTuple = (1, 2, 3, 4, 5, 6)# 找到大于1，小于4的值print(list(filter(lambda x: foo(1, x, 4), myTuple)))# (2, 3) map 12345678910def func(x, y): print(x, y) return x + ya = [1, 2]data = list(map(lambda x: func(x, 88), a))print(data)# 1 88# 2 8# [89, 90]

12345from sqlalchemy import funcquery_ = query_.filter( func.json_extract(models.Person.data, f'$.{key}') == value,)

初步了解更新锁（U）与排它锁（X） 有类似这样的表及数据12345678910111213CREATE TABLE dbo.tb( c1 int, c2 char(10), c3 varchar(10));GODECLARE @id int;SET @id = 0;WHILE @id <5BEGIN; SET @id = @id + 1; INSERT dbo.tb VALUES( @id, 'b' + RIGHT(10000 + @id, 4), 'c' + RIGHT(100000 + @id, 4) );END; 在查询一中执行更新操作12345BEGIN TRANUPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 2;WAITFOR DELAY '00:00:30';UPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 5;ROLLBACK; 在查询一执行开始后，马上在查询二中执行 ...

必要条件 互斥条件 资源是独占的且排他使用，进程互斥使用资源，即任意时刻一个资源只能给一个进程使用，其他进程若申请一个资源，而该资源被另一进程占有时，则申请者等待直到资源被占有者释放。 不可剥夺条件 进程所获得的资源在未使用完毕之前，不被其他进程强行剥夺，而只能由获得该资源的进程资源释放。 请求和保持条件 进程每次申请它所需要的一部分资源，在申请新的资源的同时，继续占用已分配到的资源。 循环等待条件 在发生死锁时必然存在一个进程等待队列{P1,P2,…,Pn},其中P1等待P2占有的资源，P2等待P3占有的资源，…，Pn等待P1占有的资源，形成一个进程等待环路，环路中每一个进程所占有的资源同时被另一个申请，也就是前一个进程占有后一个进程所深情地资源。以上给出了导致死锁的四个必要条件，只要系统发生死锁则以上四个条件至少有一个成立。事实上循环等待的成立蕴含了前三个条件的成立，似乎没有必要列出然而考虑这些条件对死锁的预防是有利的，因为可以通过破坏四个条件中的任何一个来预防死锁的发生。 死锁预防我们可以通过破坏死锁产生的4个必要条件来 预防死锁，由于资源互斥是资源使用的固有特性是 ...

记录锁（record lock）这是一个索引记录锁，它是建立在索引记录上的锁（主键和唯一索引都算），很多时候，锁定一条数据，由于无索引，往往会导致整个表被锁住，建立合适的索引可以防止扫描整个表。如：开两个会话，两个事务，并且都不commit，该表有主键，两个会话修改同一条数据，第一个会话update执行后，第二个会话的update是无法执行成功的，会进入等待状态，但是如果update别的数据行就可以成功。再例如：开两个会话，两个事务，并且都不commit，并且该表无主键无索引，那么第二个会话不管改什么都会进入等待状态。因为无索引的话，整个表的数据都被第一个会话锁定了。 间隙锁（gap lock）MySQL默认事务隔离级别是可重复读，这个隔离级别为了避免幻读现象，引入了这个间隙锁，对索引项之间的间隙上锁。 Next-key锁（Next-key lock）Next-key锁实际上是Record锁和gap锁的组合。Next-key锁是在下一个索引记录本身和索引之前的gap加上S锁或是X锁(如果是读就加上S锁，如果是写就加X锁)。默认情况下，InnoDB的事务隔离级别为RR，系统参数innod ...

在数据库里面存储一些结构化数据12345678910111213141516171819202122232425class JSON(TypeDecorator): """ Json String Field """ impl = Text def process_bind_param(self, value, dialect): if value is None: return value elif isinstance(value, (dict, list)): return json.dumps(value) else: raise ValueError("unsupported value type") def process_result_value(self, value, dialect): if value is None: ...