假如你有一个表，
SQL> CREATE TABLE test_tab (
2 id INT,
3 name VARCHAR(10),
4 age INT,
5 val VARCHAR(10)
6 );
你的业务，有一个查询，是
SELECT * FROM test_tab WHERE name = 一个外部输入的数据
刚开始，数据不多的时候，执行效果还不错。
随着数据量的增加，这个查询，执行起来，越来越慢了。
然后在 name 上面 建立了索引
CREATE INDEX idx_test4_name ON test_tab (name );
这样， 可以加快前面那个查询的速度。
但是，某天，你执行了下面这个SQL， 发现速度又慢了
SELECT * FROM test_tab WHERE age = 25
为啥呢？ 因为 age 字段上面，没有索引
索引只在 name 上面有
换句话说， 也就是 WHERE 里面的条件， 会自动判断，有没有 可用的索引，如果有， 该不该用。
多列索引，就是一个索引，包含了2个字段。
例如：
CREATE INDEX idx_test_name_age ON test_tab (name, age);
那么
SELECT * FROM test_tab
WHERE
name LIKE ‘张%’
AND age = 25
这样的查询，将能够使用上面的索引。
多列索引，还有一个可用的情况就是， 某些情况下，可能查询，只访问索引就足够了， 不需要再访问表了。例如：
SELECT
AVG( avg ) AS 平均年龄
FROM
test_tab
WHERE
name LIKE ‘张%’
这个时候， name 与 age 都包含在索引里面。 查询不需要去检索表中的数据。

选择：
select * from user where user.id=1;
插入：
insert into user(user.id,user.name,user.pwd) values('3','testname','testpwd')
insert into booktest(booktest.id,booktest.name,booktest.price,booktest.userid) values(1,'好书名',15,null)
删除：
delete from user where id=3
更新：
update user set user.name='updatename' where user.id=2
Like语句:
select * from user where user.name like '%name%'
排序：
select * from user order by user.id desc
总数：
select count(*) from user
求和：
select sum(book.price) from book
平均：
select avg(book.price) from book
最大：
select max(book.price) from book
最小：
select min(book.price) from book
left join:
select * from user u left join book b on u.id=b.userid;
Group by:
select u.id,u.name,count(*) from user u left join book b on u.id=b.userid group by u.id;
IN:
select * from book where price in(25,10)
NOT IN:
select * from book where price not in(25,10)
子查询：
select * from user where user.id in(select book.userid from book)
Between：
select * from book where book.price between 5 and 30
时间函数：
select DAYOFWEEK('1998-02-03');
select WEEKDAY('1997-10-04 22:23:00');
创建表
CREATE TABLE booktest (
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(1024) NOT NULL,
price int(10) not null,
userid int(10)
)
TABLESPACE ts_1 STORAGE DISK
ENGINE NDBCLUSTER;

亲爱的怪蜀黎：
大学毕业后我终于成为了从小梦想的一名——web程序员。在魔都这7年，我一共只在2家公司服务过，而在现在这家公司已有6个年头。前5年说不上兢兢业业，但也还算认认真真，但因为公司重点不在web一块，基本没有机会可言。所幸一年前公司开始转型，将主要资源往web一块转移。我还没反应过来，项目、待遇、职位、人手都纷涌而至。在兴奋、惶恐、忧郁中，带着一个30多人的团队做了一个最终没有太好结局的项目。虽然不成功的原因很多，但有时我想，也许我应该做的更好，也许结果会有一点不同。
不过和我的沉重相比，似乎公司并没有很在意这个结果。上个月给了我新的一个项目——这一次，放的权利更大。感谢老板的信任和支持，但肩上的压力感觉有增无减。也许犯错是成长最好的老师，失败也是人生最宝贵的财富，但我不想用这些话成为铺垫可能失败的接口。
问一个当下的疑问。新的项目至今没有专门的产品人员介入，我希望每一个研发人员都能在充分理解需求后，从运营角度设计产品，从用户体验开发功能。我并不反感产品人员，但我更憧憬研发驱动的模式，也许是因为我还没有在工作中遇到过靠谱的产品。
研发驱动说来简单，在获得执行力、灵活性，降低各种内耗和成本，实现快速迭代开发的同时，也在为研发人员的各种经验不足和程序员特有的“古怪思维”付出着代价，并承担着让项目背负上更大失败风险的可能。
一方面，我希望努力去尝试我理想中的研发驱动模式，一方面也害怕自己的一意孤行让项目触礁、让部门蒙羞。你是如何看待这个具体的问题的？或者有什么更好的建议？
当然，如果能有靠谱产品推荐，我也非常愿意接受！
首先，技术与产品合体是最优解，知行合一，效率大增，尤其减少产品观不同带来的损耗。产品争论很多时候没有对错之分，只有风格差异，所以参与讨论的人越少，执行效率越高；人越多，则无益的摩擦越多，速度越慢。
在国外，牛逼产品往往就是知行合一的工程师捣鼓出来，如Google和Facebook的工程师文化，建立在工程师文武双全的基础上，才能催生创新。我以前写过一篇《为什么不创新》，有观点云，参与创新的人数越少，创新成功的概率就越高。
所以国内文理分家，贻害万年。产品不精研技术，看代码如见梵文；技术则埋头技术，对产品管中窥豹，时见一斑。最后在99.9%的情况下，还得由产品+技术的组合去做项目，互相对上眼，磨合好的难度，已经将产品成功率降低了20倍。
回到正题。
1、
你说得对，靠谱的产品人员极少，到“产品架构”这个层级的更少了。很多人找我推荐靠谱的PM，我倒是认识这么两三个，但很难挖动。我自己创业都没打算招PM，自己挽袖子上，就是为了减少摩擦，全速前进。
还有人不断问我怎样培养PM，也回答不了，水土和品种都很重要。有些时候品种不行，有些时候根本是你们的水土也不行，我能给出的答案都是心灵鸡汤一类的万能解，有道理，没用处。
2、
如果很难信任产品人员，是否工程师自己挽袖子上呢？“每一个研发人员都能在充分理解需求后，从运营角度设计产品，从用户体验开发功能。”这句话本身的破绽很多：
-充分理解需求，需求从哪里来，需求是否正确？
-从运营角度设计，运营思路是什么，运营任务是否安排得当？
-从用户体验开发，怎么把握用户体验？是工程师本人的体验，还是道听途说来的用户反馈？
你在来信中的愿望，是一个绝对正确的大口号，即便非常资深的产品经理也不能保证自己做到，做好。否则天底下哪里来如许多产品残局。那么，你的工程师团队如何能达到，至少是接近这个目标呢？我见过大骂PM废柴的工程师，自己赤膊上阵的时候，却比废柴PM更废一筹。
3、
按照常规，产品人员分作：
-产品经理，通常兼任产品策划，管理需求、进度与品质
-产品策划，基本上只对需求与设计负责，很多时候与交互设计合体
-交互设计师，将策划案转换为交互原型
-UI设计师
-产品运营，又细分为内容运营、用户关系、活动，推广、BD等岗位
同样按照常规，以及格线为标准，国内工程师最容易兼任的是产品经理这个角色，由技术经理来兼任。普通工程师有不超过35%的可能兼任产品策划，不超过15%的可能兼任交互设计，不超过5%的可能兼任UI设计与产品运营。
你提到的“没有专门的产品人员介入”，针对以上常规，建议由产品感较好的技术主管，比如你自己，兼任PM。工程师可以提需求，提策划，由你来把关。策划案交给专业的交互设计与UI设计去实现——在极端情况下，比如没有交互设计师，产品本身的交互架构也不复杂，可以将低保真线框图直接交给UI设计师。
至于运营介入，取决于整个项目的运营思路，这大概也是PM角色来出。根据思路，按照“典型用户”的标准招聘对口的运营人员，与工程师直接对接。
以上建议，完全依赖于这个“产品感较好的技术主管”，由他来主持。如果放心大胆，权力下放到单个工程师……你有Google和Facebook那样强悍而全能的工程师吗？
如果技术主管缺乏产品自信，只剩下最后一个法子：只做自己是典型用户的项目，对于产品感将是非常大的弥补。如同Facebook的工程师驱动，取决于他们本身是Facebook的深度用户；Google在工具类应用上出类拔萃，也是同理，但重塑一个社交网络就举步维艰。
4、
我去年写了《危机感》，整个互联网行业最缺的是其实是好项目，其次才是好团队。在现有的市场基础上，需求池几近枯竭，找不到几个能出力的战场。这是整个行业共通的问题。所谓臆造需求，或者愚公移山，大都是逼出来的。假如方向偏了，就算你找到牛得一逼的产品经理(或者就是你自己)，结果也大同小异。
对此悲惨世界，我唯一能提的，勉强不算是废话的建议，是做你自己喜欢的项目，尤其做你自己是典型用户的项目，为你和你的朋友去提供服务。比较小的好处是增加对用户对市场的理解，比较大的好处，则是这个过程会令你比较开心，最终结果很难讲，至少享受了过程。
当然，如果工作环境不能提供这样的项目机会，我只能说，苦得一逼也是人生经历。
来源：http://blog.jobbole.com/20491/

如何充分利用你的技术知识？学一个技术很花时间，学会了就要充分利用它！拿它做许多项目，培养经验=>拿它讲课累积内容=>写杂志专栏累积教学内容=>把教学内容写成书（简体版）=>把书翻译成繁体出版=>把书翻译成英文出版=>视频讲课=>做成电子书=>修订增补内容，推出新版纸本书=>翻译成繁体 …