ENUM 类型

ENUM是一个字符串对象，它的取值范围是在创建表时指定的列表。它具有以下优点：

• 当一个列取值是有限范围时，可以压缩数据存储。输入的字符串会被自动编码为数字存储。具体参考：Data Type Storage Requirements
• 在查询和输出时可读性更好。在查询结果中，存储的数字会被还原为字符串。但是需要考虑一下潜在的问题：
  • 如果你将枚举类型字段的取值设置为数字时，很容易将字面量的值和MySQL内部存储的索引值混淆。详情参考:枚举类型的限制
  • 枚举类型的列用在order by子句中需要特别注意，详情参考：枚举列排序.
  • 创建并使用枚举类型的列
  • 枚举元素的索引
  • 枚举字面量处理
  • 空值或NULL值
  • 枚举列排序
  • 枚举类型的限制

字符串类型

字符串类型指CHAR、VARCHAR、BINARY、VARBINARY、BLOB、TEXT、ENUM和SET。该节描述了这些类型如何工作以及如何在查询中使用这些类型。

前言

由于CPython中GIL(Global Interpreter Lock)存在，导致Python多线程的效率针对CPU密集型的应用不友好。具体原因可以参考优秀博文:Python的GIL是什么鬼，多线程性能究竟如何。解决这个问题的办法很多，换一个Python运行环境或者换一种语言。哈哈….. 当然了你也可以使用multiprocessing

前言

每种编程语言都有自己的代码组织方式，Python也不例外。如果只是写一点简单的脚本，一般也不用不上Python的包和模块机制，当你积累的工具代码或工程代码越来越多的时候，为了更好的代码复用和结构组织就需要它的包和模块机制。

包

Python程序由包（package）、模块（module）和函数组成。包是由一系列模块组成的集合。模块是处理某一类问题的函数和类的集合。

前言

Python读取文件的方式有多种，但每种方式都有各自的不同的特点，在使用的时候需要注意这细节的不同。

文件读取

read([size])

read是最常用的文件读取方式。API的说明如下：

Read at most size uncompressed bytes, returned as a string. If the size argument is negative or omitted, read until EOF is reached.

文章转载自:python多线程

前言

Python的标准库提供了两个模块：thread和threading，thread是低级模块，threading是高级模块，对thread进行了封装。绝大多数情况下，我们只需要使用threading这个高级模块。

文章转载自:深入分析synchronized的实现原理

记得刚刚开始学习Java的时候，一遇到多线程情况就是synchronized，相对于当时的我们来说synchronized是这么的神奇而又强大，那个时候我们赋予它一个名字“同步”，也成为了我们解决多线程情况的百试不爽的良药。但是，随着我们学习的进行我们知道synchronized是一个重量级锁，相对于Lock，它会显得那么笨重，以至于我们认为它不是那么的高效而慢慢摒弃它。
诚然，随着Javs SE 1.6对synchronized进行的各种优化后，synchronized并不会显得那么重了。下面跟随LZ一起来探索synchronized的实现机制、Java是如何对它进行了优化、锁优化机制、锁的存储结构和升级过程；

前言

对python不熟。但工作中偶尔需要除了一些和数据（mysql,mongodb等），文件等相关的问题。此时第一个想到的就是python（不喜欢shell的语法）。遇到需要使用的功能每次都要查API，这个就比较翻了。这篇文章就是讲自己常用的功能代码整理起来，方便以后使用。

本文翻译自:https://blogs.oracle.com/dave/biased-locking-in-hotspot

The biased locking scheme in HotSpot arose from the following paper authored by myself, Mark Moir, and Bill Scherer. Briefly, the compare-and-swap (CAS) operations normally used to acquire a Java monitor incurs considerable local latency in the executing CPU. Since most objects are locked by at most one thread during their lifetime, we allow that thread to bias an object toward itself. Once biased, that thread can subsequently lock and unlock the object without resorting to expensive atomic instructions. Obviously, an object can be biased toward at most one thread at any given time. (We refer to that thread as the bias holding thread). If another thread tries to acquire a biased object, however, we need to revoke the bias from the original thread. (At this juncture we can either rebias the object or simply revert to normal locking for the remainder of the object’s lifetime). The key challenge in revocation is to coordinate the revoker and the revokee (the bias holding thread) – we must ensure that the revokee doesn’t lock or unlock the object during revocation. As noted in the paper, revocation can be implemented in various ways - signals, suspension, and safepoints to name a few. Critically, for biased locking to prove profitable, the benefit conferred from avoiding the atomic instructions must exceed the revocation costs. Another equivalent way to conceptualize biased locking is that the original owner simply defers unlocking the object until it encounters contention. Biased locking bears some semblance to the concept of lock reservation, which is well-described in Kawachiya’s dissertation. It’s also similar in spirit to “opportunistic locks” (oplocks) found in various file systems; the scheme describe in Mike Burrows’s “How to implement unnecessary mutexes” (In Computer Systems: Theory, Technology and Applications, Dec. 2003); or Christian Siebert’s one-sided mutual exclusion primitives.

前言

相信很多同学在多年复杂系统的开发中，应该会碰到过MySQL的死锁问题。那MySQL是如何检测死锁？发送死锁后MySQL会怎么处理呢？