Wetts's blog

Stay Hungry, Stay Foolish.

0%

方法1:直接使用数据库提供的 SQL 语句

  • 语句样式:MySQL 中,可用如下方法:SELECT * FROM 表名称 LIMIT M,N
  • 适应场景:适用于数据量较少的情况(元组百/千级)。
  • 原因/缺点:全表扫描,速度会很慢,且有的数据库结果集返回不稳定(如某次返回 1,2,3,另外的一次返回 2,1,3)。Limit 限制的是从结果集的 M 位置处取出 N 条输出,其余抛弃。

方法2:建立主键或唯一索引,利用索引(假设每页 10 条)

  • 语句样式:MySQL 中,可用如下方法:
    1
    2
    复制代码代码如下:
    SELECT * FROM 表名称 WHERE id_pk > (pageNum*10) LIMIT M。
  • 适应场景:适用于数据量多的情况(元组数上万)。
  • 原因:索引扫描,速度会很快。有朋友提出因为数据查询出来并不是按照 pk_id 排序的,所以会有漏掉数据的情况,只能方法3。

方法3:基于索引再排序

  • 语句样式:MySQL 中,可用如下方法: SELECT * FROM 表名称 WHERE id_pk > (pageNum*10) ORDER BY id_pk ASC LIMIT M
  • 适应场景:适用于数据量多的情况(元组数上万)。最好 ORDER BY 后的列对象是主键或唯一索引,使得 ORDER BY 操作能利用索引被消除但结果集是稳定的(稳定的含义,参见方法 1)。
  • 原因:索引扫描,速度会很快。但 MySQL 的排序操作,只有 ASC 没有 DESC(DESC是假的,未来会做真正的 DESC,期待)。

方法4:基于索引使用 prepare(第一个问号表示 pageNum,第二个?表示每页元组数)

  • 语句样式:MySQL 中,可用如下方法:
    1
    2
    复制代码代码如下:
    PREPARE stmt_name FROM SELECT * FROM 表名称 WHERE id_pk > (?* ?) ORDER BY id_pk ASC LIMIT M。
  • 适应场景:大数据量。
  • 原因:索引扫描,速度会很快。prepare 语句又比一般的查询语句快一点。

方法5:利用 MySQL 支持 ORDER 操作可以利用索引快速定位部分元组,避免全表扫描

  • 比如:读第 1000 到 1019 行元组(pk 是主键/唯一键)。
    1
    2
    复制代码代码如下:
    SELECT * FROM your_table WHERE pk>=1000 ORDER BY pk ASC LIMIT 0,20。

方法6:利用”子查询/连接+索引”快速定位元组的位置,然后再读取元组。道理同方法 5

  • 如(id 是主键/唯一键,蓝色字体时变量):
    1
    2
    3
    4
    5
    6
    7
    利用子查询示例:
    复制代码代码如下:
    SELECT * FROM your_table WHERE id <= (SELECT id FROM your_table ORDER BY id desc LIMIT ($page-1)*$pagesize ORDER BY id desc LIMIT $pagesize

    利用连接示例:
    复制代码代码如下:
    SELECT * FROM your_table AS t1 JOIN(SELECT id FROM your_table ORDER BY id desc LIMIT ($page-1)*$pagesize AS t2 WHERE t1.id <= t2.id ORDER BY t1.id desc LIMIT $pagesize;

方法7:存储过程类(最好融合上述方法 5/6)

  • 语句样式:不再给出
  • 适应场景:大数据量。作者推荐的方法
  • 原因:把操作封装在服务器,相对更快一些。

方法8:反面方法

  • 网上有人写使用 SQL_CALC_FOUND_ROWS。没有道理,勿模仿 。

基本上,可以推广到所有数据库,道理是一样的。但方法 5 未必能推广到其他数据库,推广的前提是,其他数据库支持 ORDER BY 操作可以利用索引直接完成排序。

## 什么是pom?

pom作为项目对象模型。通过xml表示maven项目,使用pom.xml来实现。主要描述了项目:包括配置文件;开发者需要遵循的规则,缺陷管理系统,组织和licenses,项目的url,项目的依赖性,以及其他所有的项目相关因素。

pom.xml 配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
<project>  
    <parent>  
        ...  
    </parent>  
      
    <modelVersion>4.0.0</modelVersion>  
  
    <!-- The Basics -->  
    <groupId>...</groupId>  
    <artifactId>...</artifactId>  
    <version>...</version>  
    <packaging>...</packaging>  
      
    <scm>  
        ...  
    </scm>  
      
    <dependencies>  
        ...  
    </dependencies>  
      
    <dependencyManagement>  
        ...  
    </dependencyManagement>  
      
    <modules>  
        ...  
    </modules>  
      
    <properties>  
        ...  
    </properties>  
  
    <!-- Build Settings -->  
    <build>  
        ...  
    </build>  
    <reporting>  
        ...  
    </reporting>  
  
    <!-- More Project Information -->  
    <name>...</name>  
    <description>...</description>  
    <url>...</url>  
    <inceptionYear>...</inceptionYear>  
      
    <licenses>  
    </licenses>  
      
    <organization>  
    </organization>  
      
    <developers>  
    </developers>  
      
    <contributors>  
    </contributors>  
  
    <!-- Environment Settings -->  
    <issueManagement>  
    </issueManagement>  
      
    <ciManagement>  
    </ciManagement>  
      
    <mailingLists>  
    </mailingLists>  
      
    <prerequisites>  
    </prerequisites>  
      
    <repositories>  
    </repositories>  
      
    <pluginRepositories>  
    </pluginRepositories>  
      
    <distributionManagement>  
    </distributionManagement>  
      
    <profiles>  
    </profiles>  
</project>  

maven POM.xml详解

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
<project xmlns="http://maven.apache.org/POM/4.0.0"     
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/maven-v4_0_0.xsd">     
    <!--父项目的坐标。如果项目中没有规定某个元素的值,那么父项目中的对应值即为项目的默认值。 坐标包括group ID,artifact ID和 version。-->    
    <parent>    
     <!--被继承的父项目的构件标识符-->    
     <artifactId/>    
     <!--被继承的父项目的全球唯一标识符-->    
     <groupId/>    
     <!--被继承的父项目的版本-->    
     <version/>    
     <!-- 父项目的pom.xml文件的相对路径。相对路径允许你选择一个不同的路径。默认值是../pom.xml。Maven首先在构建当前项目的地方寻找父项 目的pom,其次在文件系统的这个位置(relativePath位置),然后在本地仓库,最后在远程仓库寻找父项目的pom。-->    
     <relativePath/>    
 </parent>    
 <!--声明项目描述符遵循哪一个POM模型版本。模型本身的版本很少改变,虽然如此,但它仍然是必不可少的,这是为了当Maven引入了新的特性或者其他模型变更的时候,确保稳定性。-->       
    <modelVersion>4.0.0</modelVersion>     
    <!--项目的全球唯一标识符,通常使用全限定的包名区分该项目和其他项目。并且构建时生成的路径也是由此生成, 如com.mycompany.app生成的相对路径为:/com/mycompany/app-->     
    <groupId>asia.banseon</groupId>     
    <!-- 构件的标识符,它和group ID一起唯一标识一个构件。换句话说,你不能有两个不同的项目拥有同样的artifact ID和groupID;在某个 特定的group ID下,artifact ID也必须是唯一的。构件是项目产生的或使用的一个东西,Maven为项目产生的构件包括:JARs,源 码,二进制发布和WARs等。-->     
    <artifactId>banseon-maven2</artifactId>     
    <!--项目产生的构件类型,例如jar、war、ear、pom。插件可以创建他们自己的构件类型,所以前面列的不是全部构件类型-->     
    <packaging>jar</packaging>     
    <!--项目当前版本,格式为:主版本.次版本.增量版本-限定版本号-->     
    <version>1.0-SNAPSHOT</version>     
    <!--项目的名称, Maven产生的文档用-->     
    <name>banseon-maven</name>     
    <!--项目主页的URL, Maven产生的文档用-->     
    <url>http://www.baidu.com/banseon</url>     
    <!-- 项目的详细描述, Maven 产生的文档用。  当这个元素能够用HTML格式描述时(例如,CDATA中的文本会被解析器忽略,就可以包含HTML标 签), 不鼓励使用纯文本描述。如果你需要修改产生的web站点的索引页面,你应该修改你自己的索引页文件,而不是调整这里的文档。-->     
    <description>A maven project to study maven.</description>     
    <!--描述了这个项目构建环境中的前提条件。-->    
 <prerequisites>    
  <!--构建该项目或使用该插件所需要的Maven的最低版本-->    
    <maven/>    
 </prerequisites>    
 <!--项目的问题管理系统(Bugzilla, Jira, Scarab,或任何你喜欢的问题管理系统)的名称和URL,本例为 jira-->     
    <issueManagement>    
     <!--问题管理系统(例如jira)的名字,-->     
        <system>jira</system>     
        <!--该项目使用的问题管理系统的URL-->    
        <url>http://jira.baidu.com/banseon</url>     
    </issueManagement>     
    <!--项目持续集成信息-->    
 <ciManagement>    
  <!--持续集成系统的名字,例如continuum-->    
  <system/>    
  <!--该项目使用的持续集成系统的URL(如果持续集成系统有web接口的话)。-->    
  <url/>    
  <!--构建完成时,需要通知的开发者/用户的配置项。包括被通知者信息和通知条件(错误,失败,成功,警告)-->    
  <notifiers>    
   <!--配置一种方式,当构建中断时,以该方式通知用户/开发者-->    
   <notifier>    
    <!--传送通知的途径-->    
    <type/>    
    <!--发生错误时是否通知-->    
    <sendOnError/>    
    <!--构建失败时是否通知-->    
    <sendOnFailure/>    
    <!--构建成功时是否通知-->    
    <sendOnSuccess/>    
    <!--发生警告时是否通知-->    
    <sendOnWarning/>    
    <!--不赞成使用。通知发送到哪里-->    
    <address/>    
    <!--扩展配置项-->    
    <configuration/>    
   </notifier>    
  </notifiers>    
 </ciManagement>    
 <!--项目创建年份,4位数字。当产生版权信息时需要使用这个值。-->    
    <inceptionYear/>    
    <!--项目相关邮件列表信息-->     
    <mailingLists>    
     <!--该元素描述了项目相关的所有邮件列表。自动产生的网站引用这些信息。-->     
        <mailingList>     
         <!--邮件的名称-->    
            <name>Demo</name>     
            <!--发送邮件的地址或链接,如果是邮件地址,创建文档时,mailto: 链接会被自动创建-->     
            <post>banseon@126.com</post>     
            <!--订阅邮件的地址或链接,如果是邮件地址,创建文档时,mailto: 链接会被自动创建-->     
            <subscribe>banseon@126.com</subscribe>     
            <!--取消订阅邮件的地址或链接,如果是邮件地址,创建文档时,mailto: 链接会被自动创建-->     
            <unsubscribe>banseon@126.com</unsubscribe>     
            <!--你可以浏览邮件信息的URL-->    
            <archive>http:/hi.baidu.com/banseon/demo/dev/</archive>     
        </mailingList>     
    </mailingLists>     
    <!--项目开发者列表-->     
    <developers>     
     <!--某个项目开发者的信息-->    
        <developer>     
         <!--SCM里项目开发者的唯一标识符-->    
            <id>HELLO WORLD</id>     
            <!--项目开发者的全名-->    
            <name>banseon</name>     
            <!--项目开发者的email-->    
            <email>banseon@126.com</email>     
            <!--项目开发者的主页的URL-->    
            <url/>    
            <!--项目开发者在项目中扮演的角色,角色元素描述了各种角色-->    
            <roles>     
                <role>Project Manager</role>     
                <role>Architect</role>     
            </roles>    
            <!--项目开发者所属组织-->    
            <organization>demo</organization>     
            <!--项目开发者所属组织的URL-->    
            <organizationUrl>http://hi.baidu.com/banseon</organizationUrl>     
            <!--项目开发者属性,如即时消息如何处理等-->    
            <properties>     
                <dept>No</dept>     
            </properties>    
            <!--项目开发者所在时区, -11到12范围内的整数。-->    
            <timezone>-5</timezone>     
        </developer>     
    </developers>     
    <!--项目的其他贡献者列表-->     
    <contributors>    
     <!--项目的其他贡献者。参见developers/developer元素-->    
     <contributor>    
   <name/><email/><url/><organization/><organizationUrl/><roles/><timezone/><properties/>    
     </contributor>         
    </contributors>       
    <!--该元素描述了项目所有License列表。 应该只列出该项目的license列表,不要列出依赖项目的 license列表。如果列出多个license,用户可以选择它们中的一个而不是接受所有license。-->     
    <licenses>    
     <!--描述了项目的license,用于生成项目的web站点的license页面,其他一些报表和validation也会用到该元素。-->     
        <license>    
         <!--license用于法律上的名称-->    
            <name>Apache 2</name>     
            <!--官方的license正文页面的URL-->    
            <url>http://www.baidu.com/banseon/LICENSE-2.0.txt</url>     
            <!--项目分发的主要方式:    
              repo,可以从Maven库下载    
              manual, 用户必须手动下载和安装依赖-->    
            <distribution>repo</distribution>     
            <!--关于license的补充信息-->    
            <comments>A business-friendly OSS license</comments>     
        </license>     
    </licenses>     
    <!--SCM(Source Control Management)标签允许你配置你的代码库,供Maven web站点和其它插件使用。-->     
    <scm>     
        <!--SCM的URL,该URL描述了版本库和如何连接到版本库。欲知详情,请看SCMs提供的URL格式和列表。该连接只读。-->     
        <connection>     
            scm:svn:http://svn.baidu.com/banseon/maven/banseon/banseon-maven2-trunk(dao-trunk)      
        </connection>     
        <!--给开发者使用的,类似connection元素。即该连接不仅仅只读-->    
        <developerConnection>     
            scm:svn:http://svn.baidu.com/banseon/maven/banseon/dao-trunk      
        </developerConnection>    
        <!--当前代码的标签,在开发阶段默认为HEAD-->    
        <tag/>           
        <!--指向项目的可浏览SCM库(例如ViewVC或者Fisheye)的URL。-->     
        <url>http://svn.baidu.com/banseon</url>     
    </scm>     
    <!--描述项目所属组织的各种属性。Maven产生的文档用-->     
    <organization>     
     <!--组织的全名-->    
        <name>demo</name>     
        <!--组织主页的URL-->    
        <url>http://www.baidu.com/banseon</url>     
    </organization>    
    <!--构建项目需要的信息-->    
    <build>    
     <!--该元素设置了项目源码目录,当构建项目的时候,构建系统会编译目录里的源码。该路径是相对于pom.xml的相对路径。-->    
  <sourceDirectory/>    
  <!--该元素设置了项目脚本源码目录,该目录和源码目录不同:绝大多数情况下,该目录下的内容 会被拷贝到输出目录(因为脚本是被解释的,而不是被编译的)。-->    
  <scriptSourceDirectory/>    
  <!--该元素设置了项目单元测试使用的源码目录,当测试项目的时候,构建系统会编译目录里的源码。该路径是相对于pom.xml的相对路径。-->    
  <testSourceDirectory/>    
  <!--被编译过的应用程序class文件存放的目录。-->    
  <outputDirectory/>    
  <!--被编译过的测试class文件存放的目录。-->    
  <testOutputDirectory/>    
  <!--使用来自该项目的一系列构建扩展-->    
  <extensions>    
   <!--描述使用到的构建扩展。-->    
   <extension>    
    <!--构建扩展的groupId-->    
    <groupId/>    
    <!--构建扩展的artifactId-->    
    <artifactId/>    
    <!--构建扩展的版本-->    
    <version/>    
   </extension>    
  </extensions>    
  <!--当项目没有规定目标(Maven2 叫做阶段)时的默认值-->    
  <defaultGoal/>    
  <!--这个元素描述了项目相关的所有资源路径列表,例如和项目相关的属性文件,这些资源被包含在最终的打包文件里。-->    
  <resources>    
   <!--这个元素描述了项目相关或测试相关的所有资源路径-->    
   <resource>    
    <!-- 描述了资源的目标路径。该路径相对target/classes目录(例如${project.build.outputDirectory})。举个例 子,如果你想资源在特定的包里(org.apache.maven.messages),你就必须该元素设置为org/apache/maven /messages。然而,如果你只是想把资源放到源码目录结构里,就不需要该配置。-->    
    <targetPath/>    
    <!--是否使用参数值代替参数名。参数值取自properties元素或者文件里配置的属性,文件在filters元素里列出。-->    
    <filtering/>    
    <!--描述存放资源的目录,该路径相对POM路径-->    
    <directory/>    
    <!--包含的模式列表,例如**/*.xml.-->    
    <includes/>    
    <!--排除的模式列表,例如**/*.xml-->    
    <excludes/>    
   </resource>    
  </resources>    
  <!--这个元素描述了单元测试相关的所有资源路径,例如和单元测试相关的属性文件。-->    
  <testResources>    
   <!--这个元素描述了测试相关的所有资源路径,参见build/resources/resource元素的说明-->    
   <testResource>    
    <targetPath/><filtering/><directory/><includes/><excludes/>    
   </testResource>    
  </testResources>    
  <!--构建产生的所有文件存放的目录-->    
  <directory/>    
  <!--产生的构件的文件名,默认值是${artifactId}-${version}。-->    
  <finalName/>    
  <!--当filtering开关打开时,使用到的过滤器属性文件列表-->    
  <filters/>    
  <!--子项目可以引用的默认插件信息。该插件配置项直到被引用时才会被解析或绑定到生命周期。给定插件的任何本地配置都会覆盖这里的配置-->    
  <pluginManagement>    
   <!--使用的插件列表 。-->    
   <plugins>    
    <!--plugin元素包含描述插件所需要的信息。-->    
    <plugin>    
     <!--插件在仓库里的group ID-->    
     <groupId/>    
     <!--插件在仓库里的artifact ID-->    
     <artifactId/>    
     <!--被使用的插件的版本(或版本范围)-->    
     <version/>    
     <!--是否从该插件下载Maven扩展(例如打包和类型处理器),由于性能原因,只有在真需要下载时,该元素才被设置成enabled。-->    
     <extensions/>    
     <!--在构建生命周期中执行一组目标的配置。每个目标可能有不同的配置。-->    
     <executions>    
      <!--execution元素包含了插件执行需要的信息-->    
      <execution>    
       <!--执行目标的标识符,用于标识构建过程中的目标,或者匹配继承过程中需要合并的执行目标-->    
       <id/>    
       <!--绑定了目标的构建生命周期阶段,如果省略,目标会被绑定到源数据里配置的默认阶段-->    
       <phase/>    
       <!--配置的执行目标-->    
       <goals/>    
       <!--配置是否被传播到子POM-->    
       <inherited/>    
       <!--作为DOM对象的配置-->    
       <configuration/>    
      </execution>    
     </executions>    
     <!--项目引入插件所需要的额外依赖-->    
     <dependencies>    
      <!--参见dependencies/dependency元素-->    
      <dependency>    
       ......    
      </dependency>    
     </dependencies>         
     <!--任何配置是否被传播到子项目-->    
     <inherited/>    
     <!--作为DOM对象的配置-->    
     <configuration/>    
    </plugin>    
   </plugins>    
  </pluginManagement>    
  <!--使用的插件列表-->    
  <plugins>    
   <!--参见build/pluginManagement/plugins/plugin元素-->    
   <plugin>    
    <groupId/><artifactId/><version/><extensions/>    
    <executions>    
     <execution>    
      <id/><phase/><goals/><inherited/><configuration/>    
     </execution>    
    </executions>    
    <dependencies>    
     <!--参见dependencies/dependency元素-->    
     <dependency>    
      ......    
     </dependency>    
    </dependencies>    
    <goals/><inherited/><configuration/>    
   </plugin>    
  </plugins>    
 </build>    
 <!--在列的项目构建profile,如果被激活,会修改构建处理-->    
 <profiles>    
  <!--根据环境参数或命令行参数激活某个构建处理-->    
  <profile>    
   <!--构建配置的唯一标识符。即用于命令行激活,也用于在继承时合并具有相同标识符的profile。-->    
   <id/>    
   <!--自动触发profile的条件逻辑。Activation是profile的开启钥匙。profile的力量来自于它    
   能够在某些特定的环境中自动使用某些特定的值;这些环境通过activation元素指定。activation元素并不是激活profile的唯一方式。-->    
   <activation>    
    <!--profile默认是否激活的标志-->    
    <activeByDefault/>    
    <!--当匹配的jdk被检测到,profile被激活。例如,1.4激活JDK1.4,1.4.0_2,而!1.4激活所有版本不是以1.4开头的JDK。-->    
    <jdk/>    
    <!--当匹配的操作系统属性被检测到,profile被激活。os元素可以定义一些操作系统相关的属性。-->    
    <os>    
     <!--激活profile的操作系统的名字-->    
     <name>Windows XP</name>    
     <!--激活profile的操作系统所属家族(如 'windows')-->    
     <family>Windows</family>    
     <!--激活profile的操作系统体系结构 -->    
     <arch>x86</arch>    
     <!--激活profile的操作系统版本-->    
     <version>5.1.2600</version>    
    </os>    
    <!--如果Maven检测到某一个属性(其值可以在POM中通过${名称}引用),其拥有对应的名称和值,Profile就会被激活。如果值    
    字段是空的,那么存在属性名称字段就会激活profile,否则按区分大小写方式匹配属性值字段-->    
    <property>    
     <!--激活profile的属性的名称-->    
     <name>mavenVersion</name>    
     <!--激活profile的属性的值-->    
     <value>2.0.3</value>    
    </property>    
    <!--提供一个文件名,通过检测该文件的存在或不存在来激活profile。missing检查文件是否存在,如果不存在则激活    
    profile。另一方面,exists则会检查文件是否存在,如果存在则激活profile。-->    
    <file>    
     <!--如果指定的文件存在,则激活profile。-->    
     <exists>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/</exists>    
     <!--如果指定的文件不存在,则激活profile。-->    
     <missing>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/</missing>    
    </file>    
   </activation>    
   <!--构建项目所需要的信息。参见build元素-->    
   <build>    
    <defaultGoal/>    
    <resources>    
     <resource>    
      <targetPath/><filtering/><directory/><includes/><excludes/>    
     </resource>    
    </resources>    
    <testResources>    
     <testResource>    
      <targetPath/><filtering/><directory/><includes/><excludes/>    
     </testResource>    
    </testResources>    
    <directory/><finalName/><filters/>    
    <pluginManagement>    
     <plugins>    
      <!--参见build/pluginManagement/plugins/plugin元素-->    
      <plugin>    
       <groupId/><artifactId/><version/><extensions/>    
       <executions>    
        <execution>    
         <id/><phase/><goals/><inherited/><configuration/>    
        </execution>    
       </executions>    
       <dependencies>    
        <!--参见dependencies/dependency元素-->    
        <dependency>    
         ......    
        </dependency>    
       </dependencies>    
       <goals/><inherited/><configuration/>    
      </plugin>    
     </plugins>    
    </pluginManagement>    
    <plugins>    
     <!--参见build/pluginManagement/plugins/plugin元素-->    
     <plugin>    
      <groupId/><artifactId/><version/><extensions/>    
      <executions>    
       <execution>    
        <id/><phase/><goals/><inherited/><configuration/>    
       </execution>    
      </executions>    
      <dependencies>    
       <!--参见dependencies/dependency元素-->    
       <dependency>    
        ......    
       </dependency>    
      </dependencies>    
      <goals/><inherited/><configuration/>    
     </plugin>    
    </plugins>    
   </build>    
   <!--模块(有时称作子项目) 被构建成项目的一部分。列出的每个模块元素是指向该模块的目录的相对路径-->    
   <modules/>    
   <!--发现依赖和扩展的远程仓库列表。-->    
   <repositories>    
    <!--参见repositories/repository元素-->    
    <repository>    
     <releases>    
      <enabled/><updatePolicy/><checksumPolicy/>    
     </releases>    
     <snapshots>    
      <enabled/><updatePolicy/><checksumPolicy/>    
     </snapshots>    
     <id/><name/><url/><layout/>    
    </repository>    
   </repositories>    
   <!--发现插件的远程仓库列表,这些插件用于构建和报表-->    
   <pluginRepositories>    
    <!--包含需要连接到远程插件仓库的信息.参见repositories/repository元素-->        
    <pluginRepository>    
     <releases>    
      <enabled/><updatePolicy/><checksumPolicy/>    
     </releases>    
     <snapshots>    
      <enabled/><updatePolicy/><checksumPolicy/>    
     </snapshots>    
     <id/><name/><url/><layout/>    
    </pluginRepository>    
   </pluginRepositories>    
   <!--该元素描述了项目相关的所有依赖。 这些依赖组成了项目构建过程中的一个个环节。它们自动从项目定义的仓库中下载。要获取更多信息,请看项目依赖机制。-->    
   <dependencies>    
    <!--参见dependencies/dependency元素-->    
    <dependency>    
     ......    
    </dependency>    
   </dependencies>    
   <!--不赞成使用. 现在Maven忽略该元素.-->    
   <reports/>       
   <!--该元素包括使用报表插件产·生报表的规范。当用户执行“mvn site”,这些报表就会运行。 在页面导航栏能看到所有报表的链接。参见reporting元素-->    
   <reporting>    
    ......    
   </reporting>    
   <!--参见dependencyManagement元素-->    
   <dependencyManagement>    
    <dependencies>    
     <!--参见dependencies/dependency元素-->    
     <dependency>    
      ......    
     </dependency>    
    </dependencies>    
   </dependencyManagement>    
   <!--参见distributionManagement元素-->    
   <distributionManagement>    
    ......    
   </distributionManagement>    
   <!--参见properties元素-->    
   <properties/>    
  </profile>    
 </profiles>    
 <!--模块(有时称作子项目) 被构建成项目的一部分。列出的每个模块元素是指向该模块的目录的相对路径-->    
 <modules/>    
    <!--发现依赖和扩展的远程仓库列表。-->     
    <repositories>     
     <!--包含需要连接到远程仓库的信息-->    
        <repository>    
         <!--如何处理远程仓库里发布版本的下载-->    
         <releases>    
          <!--true或者false表示该仓库是否为下载某种类型构件(发布版,快照版)开启。 -->    
    <enabled/>    
    <!--该元素指定更新发生的频率。Maven会比较本地POM和远程POM的时间戳。这里的选项是:always(一直),daily(默认,每日),interval:X(这里X是以分钟为单位的时间间隔),或者never(从不)。-->    
    <updatePolicy/>    
    <!--当Maven验证构件校验文件失败时该怎么做:ignore(忽略),fail(失败),或者warn(警告)。-->    
    <checksumPolicy/>    
   </releases>    
   <!-- 如何处理远程仓库里快照版本的下载。有了releases和snapshots这两组配置,POM就可以在每个单独的仓库中,为每种类型的构件采取不同的 策略。例如,可能有人会决定只为开发目的开启对快照版本下载的支持。参见repositories/repository/releases元素 -->    
   <snapshots>    
    <enabled/><updatePolicy/><checksumPolicy/>    
   </snapshots>    
   <!--远程仓库唯一标识符。可以用来匹配在settings.xml文件里配置的远程仓库-->    
   <id>banseon-repository-proxy</id>     
   <!--远程仓库名称-->    
            <name>banseon-repository-proxy</name>     
            <!--远程仓库URL,按protocol://hostname/path形式-->    
            <url>http://192.168.1.169:9999/repository/</url>     
            <!-- 用于定位和排序构件的仓库布局类型-可以是default(默认)或者legacy(遗留)。Maven 2为其仓库提供了一个默认的布局;然 而,Maven 1.x有一种不同的布局。我们可以使用该元素指定布局是default(默认)还是legacy(遗留)。-->    
            <layout>default</layout>               
        </repository>     
    </repositories>    
    <!--发现插件的远程仓库列表,这些插件用于构建和报表-->    
    <pluginRepositories>    
     <!--包含需要连接到远程插件仓库的信息.参见repositories/repository元素-->    
  <pluginRepository>    
   ......    
  </pluginRepository>    
 </pluginRepositories>    
       
    <!--该元素描述了项目相关的所有依赖。 这些依赖组成了项目构建过程中的一个个环节。它们自动从项目定义的仓库中下载。要获取更多信息,请看项目依赖机制。-->     
    <dependencies>     
        <dependency>    
   <!--依赖的group ID-->    
            <groupId>org.apache.maven</groupId>     
            <!--依赖的artifact ID-->    
            <artifactId>maven-artifact</artifactId>     
            <!--依赖的版本号。 在Maven 2里, 也可以配置成版本号的范围。-->    
            <version>3.8.1</version>     
            <!-- 依赖类型,默认类型是jar。它通常表示依赖的文件的扩展名,但也有例外。一个类型可以被映射成另外一个扩展名或分类器。类型经常和使用的打包方式对应, 尽管这也有例外。一些类型的例子:jar,war,ejb-client和test-jar。如果设置extensions为 true,就可以在 plugin里定义新的类型。所以前面的类型的例子不完整。-->    
            <type>jar</type>    
            <!-- 依赖的分类器。分类器可以区分属于同一个POM,但不同构建方式的构件。分类器名被附加到文件名的版本号后面。例如,如果你想要构建两个单独的构件成 JAR,一个使用Java 1.4编译器,另一个使用Java 6编译器,你就可以使用分类器来生成两个单独的JAR构件。-->    
            <classifier></classifier>    
            <!--依赖范围。在项目发布过程中,帮助决定哪些构件被包括进来。欲知详情请参考依赖机制。    
                - compile :默认范围,用于编译      
                - provided:类似于编译,但支持你期待jdk或者容器提供,类似于classpath      
                - runtime: 在执行时需要使用      
                - test:    用于test任务时使用      
                - system: 需要外在提供相应的元素。通过systemPath来取得      
                - systemPath: 仅用于范围为system。提供相应的路径      
                - optional:   当项目自身被依赖时,标注依赖是否传递。用于连续依赖时使用-->     
            <scope>test</scope>       
            <!--仅供system范围使用。注意,不鼓励使用这个元素,并且在新的版本中该元素可能被覆盖掉。该元素为依赖规定了文件系统上的路径。需要绝对路径而不是相对路径。推荐使用属性匹配绝对路径,例如${java.home}。-->    
            <systemPath></systemPath>     
            <!--当计算传递依赖时, 从依赖构件列表里,列出被排除的依赖构件集。即告诉maven你只依赖指定的项目,不依赖项目的依赖。此元素主要用于解决版本冲突问题-->    
            <exclusions>    
             <exclusion>     
                    <artifactId>spring-core</artifactId>     
                    <groupId>org.springframework</groupId>     
                </exclusion>     
            </exclusions>       
            <!--可选依赖,如果你在项目B中把C依赖声明为可选,你就需要在依赖于B的项目(例如项目A)中显式的引用对C的依赖。可选依赖阻断依赖的传递性。-->     
            <optional>true</optional>    
        </dependency>    
    </dependencies>    
    <!--不赞成使用. 现在Maven忽略该元素.-->    
    <reports></reports>    
    <!--该元素描述使用报表插件产生报表的规范。当用户执行“mvn site”,这些报表就会运行。 在页面导航栏能看到所有报表的链接。-->    
 <reporting>    
  <!--true,则,网站不包括默认的报表。这包括“项目信息”菜单中的报表。-->    
  <excludeDefaults/>    
  <!--所有产生的报表存放到哪里。默认值是${project.build.directory}/site。-->    
  <outputDirectory/>    
  <!--使用的报表插件和他们的配置。-->    
  <plugins>    
   <!--plugin元素包含描述报表插件需要的信息-->    
   <plugin>    
    <!--报表插件在仓库里的group ID-->    
    <groupId/>    
    <!--报表插件在仓库里的artifact ID-->    
    <artifactId/>    
    <!--被使用的报表插件的版本(或版本范围)-->    
    <version/>    
    <!--任何配置是否被传播到子项目-->    
    <inherited/>    
    <!--报表插件的配置-->    
    <configuration/>    
    <!--一组报表的多重规范,每个规范可能有不同的配置。一个规范(报表集)对应一个执行目标 。例如,有1,2,3,4,5,6,7,8,9个报表。1,2,5构成A报表集,对应一个执行目标。2,5,8构成B报表集,对应另一个执行目标-->    
    <reportSets>    
     <!--表示报表的一个集合,以及产生该集合的配置-->    
     <reportSet>    
      <!--报表集合的唯一标识符,POM继承时用到-->    
      <id/>    
      <!--产生报表集合时,被使用的报表的配置-->    
      <configuration/>    
      <!--配置是否被继承到子POMs-->    
      <inherited/>    
      <!--这个集合里使用到哪些报表-->    
      <reports/>    
     </reportSet>    
    </reportSets>    
   </plugin>    
  </plugins>    
 </reporting>    
 <!-- 继承自该项目的所有子项目的默认依赖信息。这部分的依赖信息不会被立即解析,而是当子项目声明一个依赖(必须描述group ID和 artifact ID信息),如果group ID和artifact ID以外的一些信息没有描述,则通过group ID和artifact ID 匹配到这里的依赖,并使用这里的依赖信息。-->    
 <dependencyManagement>    
  <dependencies>    
   <!--参见dependencies/dependency元素-->    
   <dependency>    
    ......    
   </dependency>    
  </dependencies>    
 </dependencyManagement>       
    <!--项目分发信息,在执行mvn deploy后表示要发布的位置。有了这些信息就可以把网站部署到远程服务器或者把构件部署到远程仓库。-->     
    <distributionManagement>    
        <!--部署项目产生的构件到远程仓库需要的信息-->    
        <repository>    
         <!--是分配给快照一个唯一的版本号(由时间戳和构建流水号)?还是每次都使用相同的版本号?参见repositories/repository元素-->    
   <uniqueVersion/>    
   <id>banseon-maven2</id>     
   <name>banseon maven2</name>     
            <url>file://${basedir}/target/deploy</url>     
            <layout/>    
  </repository>    
  <!--构件的快照部署到哪里?如果没有配置该元素,默认部署到repository元素配置的仓库,参见distributionManagement/repository元素-->     
  <snapshotRepository>    
   <uniqueVersion/>    
   <id>banseon-maven2</id>    
            <name>Banseon-maven2 Snapshot Repository</name>    
            <url>scp://svn.baidu.com/banseon:/usr/local/maven-snapshot</url>     
   <layout/>    
  </snapshotRepository>    
  <!--部署项目的网站需要的信息-->     
        <site>    
         <!--部署位置的唯一标识符,用来匹配站点和settings.xml文件里的配置-->     
            <id>banseon-site</id>     
            <!--部署位置的名称-->    
            <name>business api website</name>     
            <!--部署位置的URL,按protocol://hostname/path形式-->    
            <url>     
                scp://svn.baidu.com/banseon:/var/www/localhost/banseon-web      
            </url>     
        </site>    
  <!--项目下载页面的URL。如果没有该元素,用户应该参考主页。使用该元素的原因是:帮助定位那些不在仓库里的构件(由于license限制)。-->    
  <downloadUrl/>    
  <!--如果构件有了新的group ID和artifact ID(构件移到了新的位置),这里列出构件的重定位信息。-->    
  <relocation>    
   <!--构件新的group ID-->    
   <groupId/>    
   <!--构件新的artifact ID-->    
   <artifactId/>    
   <!--构件新的版本号-->    
   <version/>    
   <!--显示给用户的,关于移动的额外信息,例如原因。-->    
   <message/>    
  </relocation>    
  <!-- 给出该构件在远程仓库的状态。不得在本地项目中设置该元素,因为这是工具自动更新的。有效的值有:none(默认),converted(仓库管理员从 Maven 1 POM转换过来),partner(直接从伙伴Maven 2仓库同步过来),deployed(从Maven 2实例部 署),verified(被核实时正确的和最终的)。-->    
  <status/>           
    </distributionManagement>    
    <!--以值替代名称,Properties可以在整个POM中使用,也可以作为触发条件(见settings.xml配置文件里activation元素的说明)。格式是<name>value</name>。-->    
    <properties/>    
</project>    

pom.xml位于创建的项目文件夹内,setting.xml位于maven包解压后conf文件夹内。

settings.xml

先来说说settings.xml,settings.xml对于maven来说相当于全局性的配置,用于所有的项目。在maven2中存在两个 settings.xml,一个位于maven2的解压目录conf下面,作为全局性配置。对于团队设置,保持一致的定义是关键,所以 maven2/conf下面的settings.xml就作为团队共同的配置文件,保证所有的团队成员都拥有相同的配置。当然对于每个成员,都需要特殊的自定义设置,如用户信息,所以另外一个settings.xml就作为本地配置。

settings.xml基本结构如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<settings xmlns=”http://maven.apache.org/POM/4.0.0″

xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0

http://maven.apache.org/xsd/settings-1.0.0.xsd”>

<localRepository/>

<interactiveMode/>

<usePluginRegistry/>

<offline/>

<pluginGroups/>

<servers/>

<mirrors/>

<proxies/>

<profiles/>

<activeProfiles/>

</settings>

几个主要的、常用的配置因素:

  1. localRepository:表示本地库的保存位置,也就是maven2主要的jar保存位置,默认在${user.dir}/.m2/repository,如需要另外设置,就换成其他的路径,如::\repo。

  2. offline:如果不想每次编译,都去查找远程中心库,那就设置为true。当然前提是你已经下载了必须的依赖包。

  3. Servers: 在POM中的 distributionManagement元素定义了开发库。然而,特定的username和pwd不能使用于pom.xml,所以通过此配置来保存server信息:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    <servers>
    <server>
    <id>server001</id>
    <username>guangyuan</username>
    <password>my_password</password>
    <privateKey>${usr.home}/.ssh/id_dsa</privateKey>
    <passphrase>some_passphrase</passphrase>
    <filePermissions>664</filePermissions>
    <directoryPermissions>775</directoryPermissions>
    <configuration></configuration>
    </server>
    </servers>
  • id:server 的id,用于匹配distributionManagement库id,比较重要。
  • username, password:用于登陆此服务器的用户名和密码
  • privateKey, passphrase:设置private key,以及passphrase
  • filePermissions, directoryPermissions:当库文件或者目录创建后,需要使用权限进行访问。参照unix文件许可,如664和775
  1. Mirrors 表示镜像库,指定库的镜像,用于增加其他库:
    1
    2
    3
    4
    5
    6
    7
    8
    <mirrors>
    <mirror>
    <id>tb_mirror</id>
    <name>taobao mirror</name>
    <url>http://downloads.planetmirror.com/pub/maven2</url>
    <mirrorOf>central</mirrorOf>
    </mirror>
    </mirrors>
  • id,name:唯一的标志,用于区别镜像
  • url:镜像的url
  • mirrorOf:此镜像指向的服务id
  1. Proxies 此代理设置,主要用于无法直接访问中心的库用户配置。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    <proxies>
    <proxy>
    <id>myproxy</id>
    <active>true</active>
    <protocol>http</protocol>
    <host>proxy.somewhere.com</host>
    <port>8080</port>
    <username>proxyuser</username>
    <password>somepassword</password>
    <nonProxyHosts>*.google.com|ibiblio.org</nonProxyHosts>
    </proxy>
    </proxies>
  • id:代理的标志
  • active:是否激活代理
  • protocol, host, port:protocol://host:port 代理
  • username, password:用户名和密码
  • nonProxyHosts: 不需要代理的host
  1. repositories 和pluginRepositories 定义其他开发库和插件开发库。对于团队来说,肯定有自己的开发库。可以通过此配置来定义。 如下的配置,定义了本地开发库,用于release 发布。pluginRepositories 的定义与repositories类似。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    <repositories>
    <repository>
    <id>repo-local</id>
    <name>Internal 开发库</name>
    <url>http://192.168.0.2:8082/repo-local</url>
    <releases>
    <enabled>true</enabled>
    <updatePolicy>never</updatePolicy>
    <checksumPolicy>warn</checksumPolicy>
    </releases>
    <snapshots>
    <enabled>false</enabled>
    </snapshots>
    <layout>default</layout>
    </repository>
    </repositories>
  • releases, snapshots:每个产品的版本的Release或者snapshot(注:release和snapshot的区别,release一般是比较稳定的版本,而snapshot基本上不稳定,只是作为快照)。

关于setting.xml里的常用配置主要就是上面的这些了。事实上,在实际项目应用中,我们只需要重点理解这些配置的意思就足够了。但如果想自己开发一个项目,那么下面的这些配置说明就显得尤为重要了。

pom.xml

通过在 pom.xml 中定义 jar 包版本和依赖,能够方便的管理 jar 文件。pom作为项目对象模型。通过xml表示maven项目,使用pom.xml来实现。主要描述了项目:包括配置文件;开发者需要遵循的规则,缺陷管理系统,组织和licenses,项目的url,项目的依赖性,以及其他所有的项目相关因素。

转自:http://stackoverflow.com/questions/581521/whats-faster-select-distinct-or-group-by-in-mysql

They are essentially equivalent to each other (in fact this is how some databases implement DISTINCT under the hood).

If one of them is faster, it’s going to be DISTINCT. This is because, although the two are the same, a query optimizer would have to catch the fact that your GROUP BY is not taking advantage of any group members, just their keys. DISTINCT makes this explicit, so you can get away with a slightly dumber optimizer.

When in doubt, test!


If you have an index on profession, these two are synonyms.

If you don’t, then use DISTINCT.

GROUP BY in MySQL sorts results. You can even do:

1
SELECT u.profession FROM users u GROUP BY u.profession DESC

and get your professions sorted in DESC order.

DISTINCT creates a temporary table and uses it for storing duplicates. GROUP BY does the same, but sortes the distinct results afterwards.

So

1
SELECT DISTINCT u.profession FROM users u

is faster, if you don’t have an index on profession.

Insert 是 T-sql 中常用语句,Insert INTO table(field1,field2,...) values(value1,value2,...)这种形式的在应用程序开发中必不可少。但我们在开发、测试过程中,经常会遇到需要表复制的情况,如将一个 table1 的数据的部分字段复制到 table2 中,或者将整个 table1 复制到 table2 中,这时候我们就要使用 SELECT INTO 和 INSERT INTO SELECT 表复制语句了。

INSERT INTO SELECT 语句

语句形式为:Insert into Table2(field1,field2,...) select value1,value2,... from Table1

要求目标表 Table2 必须存在,由于目标表 Table2 已经存在,所以我们除了插入源表 Table1 的字段外,还可以插入常量。

SELECT INTO FROM 语句

语句形式为:SELECT vale1, value2 into Table2 from Table1

要求目标表 Table2 不存在,因为在插入时会自动创建表 Table2,并将 Table1 中指定字段数据复制到 Table2 中。

SQL Server用法。

MySQL

MySQL 不支持: Select * Into new_table_name from old_table_name;

替代方法: Create table new_table_name (Select * from old_table_name);

rollup

rollup 是根据维度在数据结果集中进行的聚合操作。

假设用户需要对 N 个唯独进行聚合查询操作,普通的 group by 语句需要 N 个查询和 N 次 group by 操作。

而 rollup 的有点是一次可以去的 N 次 group by 的结果,这样可以提高查询效率,同时大大减少网络的传输流量。

(注,此表的表结构和数据与格式化聚合表 formatting 一致)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE TABLE rollup(
orderid int NOT NULL,
orderdate date NOT NULL,
empid int NOT NULL,
custid varchar(10) NOT NULL,
qty int NOT NULL,
PRIMARY KEY(orderid,orderdate));

INSERT INTO rollup SELECT 1,'2010-01-02',3,'A',10;
INSERT INTO rollup SELECT 2,'2010-04-02',2,'B',20;
INSERT INTO rollup SELECT 3,'2010-05-02',1,'A',30;
INSERT INTO rollup SELECT 4,'2010-07-02',3,'D',40;
INSERT INTO rollup SELECT 5,'2011-01-02',4,'A',20;
INSERT INTO rollup SELECT 6,'2011-01-02',3,'B',30;
INSERT INTO rollup SELECT 7,'2011-01-02',1,'C',40;
INSERT INTO rollup SELECT 8,'2009-01-02',2,'A',10;
INSERT INTO rollup SELECT 9,'2009-01-02',3,'B',20;

首先做一个简单的一维聚合

1
2
3
4
SELECT YEAR(orderdate) year, SUM(qty) sum 
FROM rollup
GROUP BY YEAR(orderdate)
WITH ROLLUP;

结果为

1

和普通的 group by 差别不大,只是多了一个 (null,220),表示对所有的 year 再做一次聚合,即订单数量总和。

对单个唯独进行 rollup 操作只是可以在最后得到聚合的数据,对比 group by 语句并没有非常大的优势。

对多个维度进行 rollup 才能体现出 rollup 的优势:

(对 3 列进行层次的维度操作)

1
2
3
4
SELECT empid, custid, YEAR(orderdate) year, SUM(qty) sum
FROM rollup
GROUP BY empid,custid,YEAR(orderdate)
WITH ROLLUP;

结果为

2

其中 (null,null,null) 表示最后的聚合

(empid,custid,year) 表示对这 3 列进行分组的聚合结果

(empid,custid,null) 表示对 (empid,custid) 两列进行分组的聚合结果

(empid,null,null) 表示仅对 (empid) 一列进行分组的聚合结果

所以上述语句等同于(但未排序)

1
2
3
4
5
6
7
8
9
10
SELECT empid, custid, YEAR(orderdate) YEAR, SUM(qty) sum FROM rollup
GROUP BY empid, custid, YEAR(orderdate)
UNION
SELECT empid, custid, NULL, SUM(qty) sum FROM rollup
GROUP BY empid, custid
UNION
SELECT empid, NULL, NULL, SUM(qty) sum FROM rollup
GROUP BY empid
UNION
SELECT NULL, NULL, NULL, SUM(qty) sum FROM rollup

虽然两者得到相同的结果,但是执行计划却不同

rollup 只需要一次表扫描操作就能得到全部结果,因此查询效率在此得到了极大的提升。

P.S.在使用 rollup 需要注意以下几方面

  1. ORDER BY 不能在 rollup 中使用,两者为互斥关键字,如果使用,会抛出以下错误:Error Code:1221. Incorrect usage of CUBE/ROLLUP and ORDER BY
  2. 可以使用 LIMIT,但是因为不能使用 order by,所以阅读性下降,故大多数情况下无实际意义。
  3. 如果分组的列包含 NULL 值,那么 rollup 的结果可能不正确

因为在 rollup 中进行的分组统计时,null 具有特殊意义

因此在进行 rollup 时可以先将 null 转换成一个不可能存在的值,或者没有特别含义的值,比如:IFNULL(xxx,0)

cube

rollup 是 cube 的一种特殊情况,和 rollup 一样,cube 也是一种对数据的聚合操作

但是 rollup 只在层次上对数据进行聚合,而 cube 对所有的维度进行聚合

具有 N 个维度的列,cube 需要 2 的 N 次方次分组操作,而 rollup 只需要 N 次分组操作

在 mysql 5.6.17 版本中,只定义了 cube,但是不支持 cube 操作:

1
2
3
4
SELECT empid, custid, YEAR(orderdate), SUM(qty)
FROM rollup
GROUP BY empid, custid, YEAR(orderdate)
WITH CUBE;

上述 SQL 语句会报错:

1
-- ERROR 1235 (42000): This version of MySQL doesn't yet support 'CUBE'

可以通过 rollup 来模拟 cube:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
SELECT 
    empid, custid, YEAR(orderdate) year, SUM(qty) sum from rollup
GROUP BY empid, custid, YEAR(orderdate)
WITH ROLLUP
UNION
SELECT 
    empid, custid, YEAR(orderdate) year, SUM(qty) sum from rollup
GROUP BY empid, YEAR(orderdate), custid
WITH ROLLUP
UNION
SELECT 
    empid, custid, YEAR(orderdate) year, SUM(qty) sum from rollup
GROUP BY custid, YEAR(orderdate),empid
WITH ROLLUP
UNION
SELECT 
    empid, custid, YEAR(orderdate) year, SUM(qty) sum from rollup
GROUP BY custid, empid, YEAR(orderdate)
WITH ROLLUP
UNION
SELECT 
    empid,custid,YEAR(orderdate) year, SUM(qty) sum from rollup
GROUP BY YEAR(orderdate), empid, custid
WITH ROLLUP
UNION
SELECT 
    empid,custid,YEAR(orderdate) year, SUM(qty) sum from rollup
GROUP BY YEAR(orderdate), custid, empid 
WITH ROLLUP;

产生的最终结果为:

3

10.12.6

  • 隐藏dock:option + command + d
  • 全屏:control + command + f

转自:http://sspai.com/28012

从 Mac 电脑上卸载已经安装的应用程序可能是你知道的操作系统里面最简单的一种了。而如果你是一名新买了 Mac 电脑的用户,那么你可能比较困惑:怎么没有控制面板中的相应板块来卸载它们呢?但是其实你想不到,在 Mac 电脑上卸载应用程序这一点简直简单得要命。本文就来讨论讨论如何卸载 Mac 电脑已经装好的应用程序。

最经典的方法

这是 OS X 最经典的方法。你只需找到需要卸载的应用程序,然后拖动应用程序图标到垃圾桶;或右键单击并选择「移到废纸篓」选项;或直接按下 command-delete 快捷键组合。然后在废纸篓图标上单机鼠标右键,选择「清倒废纸篓」选项。

1

使用 LaunchPad

如果你的应用程序来自 Mac App Store,那么你可以更快一点:

第一步:启动 LaunchPad 应用程序(或者按下键盘 F4 键)。

第二步:点击并按住你要卸载的应用程序的图标直至它们开始晃动起来,点击左上角的「X」按钮;或者按下 option 键不放进入抖动模式。

第三步:点击「删除」,接着确认即可。

2

▲ 注:这时都不用清空废纸篓。

使用 LaunchPad 来卸载是在运行 OS X 10.7 以及更高版本的电脑上最快的方法。如果你使用 iOS 设备,应该对此卸载方法很熟悉。

求助第三方应用程序

你还可以使用 Clean My Mac 或 CCleaner 或是 AppCleaner 来进行卸载。

3

(▲ 注:Clean My Mac 卸载)

4

(▲ 注:CCleaner 卸载)

5

(▲ 注:CCleaner 卸载)

有了第三方应用程序的帮助,卸载过程简单多了。此外,这些第三方卸载程序还会顺带删除一些关联的库文件、配置文档等,着实方便。

使用应用程序自带的卸载程序

你可能会注意到,某些应用程序安装完毕后居然包括独立的卸载工具。这在 Mac 上有些罕见,但的确有些应用程序这么特立独行:通常是 Adobe 家或者微软家的软件。例如,Adobe 公司的 Photoshop 应用程序可能在安装主程序的同时安装 Adobe Bridge 等附加应用程序。这种情况下,你可以使用附带的卸载程序来帮忙。

6

扫尾工作:删除应用程序的库文件,缓存,首选项

卸载某些应用程序后会留下一些预置文件和缓存等,一般这些文件没有潜在坏处,但是你可以删除它们来彻底跟该应用程序说拜拜。这些文件通常位于以下路径:

1
2
3
~/Library/Application Support/(应用程序名称)
~/Library/Preferences/(应用程序名称)
~/Library/Caches/(应用程序名称)

注:有时你会需要寻找开发商名称,而不是应用程序的名称,因为并不是所有的应用程序文件都是由它们的名称标识出来的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/Applications/Paragon NTFS for Mac OS X /Manual.pdf
/Applications/Paragon NTFS for Mac OS X/Register NTFS for Mac OS X.app
/Library/Application Support/Paragon NTFS for Mac OS X/NTFS for Mac OS X.app
/Library/PreferencePanes/NTFSforMacOSX.prefPane
/System/Library/Filesystems/ufsd_NTFS.fs
/System/Library/LaunchAgents/com.paragon.NTFS.trial.plist
/etc/mach_init_per_user.d/trial_expired_NTFS.plist
/sbin/fsck_ufsd_NTFS
/sbin/mount_ufsd_NTFS
/sbin/newfs_ufsd_NTFS
/usr/lib/libUFSDNTFS.dylib
/usr/sbin/fsctl_ufsd
/Library/Logs/ufsd.log
/tmp/ufsd.log
/usr/share/.intelligence
/Library/Receipts/$PRODUCT.pkg/Archive.bom

Redis 中数据存储模式有 2 种:cache-only、persistence

  • cache-only 即只做为“缓存”服务,不持久数据,数据在服务终止后将消失,此模式下也将不存在“数据恢复”的手段,是一种安全性低/效率高/容易扩展的方式;
  • persistence 即为内存中的数据持久备份到磁盘文件,在服务重启后可以恢复,此模式下数据相对安全。

对于 persistence 持久化存储,Redis 提供了两种持久化方法:

  • Redis DataBase(简称 RDB)
  • Append-only file(简称 AOF)

除了这两种方法,Redis 在早起的版本还存在虚拟内存的方法,现在已经被废弃。

RDB

RDB概述

RDB 是在某个时间点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据恢复。

  • 优点:使用单独子进程来进行持久化,主进程不会进行任何 I/O 操作,保证了 redis 的高性能
  • 缺点:RDB 是间隔一段时间进行持久化,如果持久化之间 redis 发生故障,会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

这里说的这个执行数据写入到临时文件的时间点是可以通过配置来自己确定的,通过配置 redis 在 n 秒内如果超过 m 个 key 被修改这执行一次 RDB 操作。这个操作就类似于在这个时间点来保存一次 Redis 的所有数据,一次快照数据。所有这个持久化方法也通常叫做 snapshots。

RDB 默认开启,redis.conf 中的具体配置参数如下;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#dbfilename:持久化数据存储在本地的文件
dbfilename dump.rdb
#dir:持久化数据存储在本地的路径,如果是在/redis/redis-3.0.6/src下启动的redis-cli,则数据会存储在当前src目录下
dir ./
##snapshot触发的时机,save <seconds> <changes>
##如下为900秒后,至少有一个变更操作,才会snapshot
##对于此值的设置,需要谨慎,评估系统的变更操作密集程度
##可以通过“save “””来关闭snapshot功能
#save时间,以下分别表示更改了1个key时间隔900s进行持久化存储;更改了10个key300s进行存储;更改10000个key60s进行存储。
save 900 1
save 300 10
save 60 10000
##当snapshot时出现错误无法继续时,是否阻塞客户端“变更操作”,“错误”可能因为磁盘已满/磁盘故障/OS级别异常等
stop-writes-on-bgsave-error yes
##是否启用rdb文件压缩,默认为“yes”,压缩往往意味着“额外的cpu消耗”,同时也意味这较小的文件尺寸以及较短的网络传输时间
rdbcompression yes

snapshot 触发的时机,是有“间隔时间”和“变更次数”共同决定,同时符合 2 个条件才会触发 snapshot,否则“变更次数”会被继续累加到下一个“间隔时间”上。snapshot 过程中并不阻塞客户端请求。snapshot 首先将数据写入临时文件,当成功结束后,将临时文件重名为 dump.rdb。

使用 RDB 恢复数据:

自动的持久化数据存储到 dump.rdb 后。实际只要重启 redis 服务即可完成(启动 redis 的 server 时会从 dump.rdb 中先同步数据)

客户端使用命令进行持久化save存储:

1
2
./redis-cli -h ip -p port save
./redis-cli -h ip -p port bgsave

一个是在前台进行存储,一个是在后台进行存储。我的 client 就在 server 这台服务器上,所以不需要连其他机器,直接 ./redis-cli bgsave。由于 redis 是用一个主线程来处理所有 client 的请求,这种方式会阻塞所有 client 请求。所以不推荐使用。另一点需要注意的是,每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步脏数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘 I/O 操作,可能会严重影响性能。

AOF

AOF概述

Append-only file,将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部,在 append 操作返回后(已经写入到文件或者即将写入),才进行实际的数据变更,“日志文件”保存了历史所有的操作过程;当 server 需要数据恢复时,可以直接 replay 此日志文件,即可还原所有的操作过程。AOF 相对可靠,它和 MySQL 中 bin.log、apache.log、zookeeper 中 txn-log 简直异曲同工。AOF 文件内容是字符串,非常容易阅读和解析。

  • 优点:可以保持更高的数据完整性,如果设置追加 file 的时间是 1s,如果 redis 发生故障,最多会丢失 1s 的数据;且如果日志写入不完整支持 redis-check-aof 来进行日志修复;AOF 文件没被 rewrite 之前(文件过大时会对命令进行合并重写),可以删除其中的某些命令(比如误操作的 flushall)。
  • 缺点:AOF 文件比 RDB 文件大,且恢复速度慢。

我们可以简单的认为 AOF 就是日志文件,此文件只会记录“变更操作”(例如:set/del 等),如果 server 中持续的大量变更操作,将会导致 AOF 文件非常的庞大,意味着 server 失效后,数据恢复的过程将会很长;事实上,一条数据经过多次变更,将会产生多条 AOF 记录,其实只要保存当前的状态,历史的操作记录是可以抛弃的;因为 AOF 持久化模式还伴生了“AOF rewrite”。

AOF 的特性决定了它相对比较安全,如果你期望数据更少的丢失,那么可以采用 AOF 模式。如果 AOF 文件正在被写入时突然 server 失效,有可能导致文件的最后一次记录是不完整,你可以通过手工或者程序的方式去检测并修正不完整的记录,以便通过 aof 文件恢复能够正常;同时需要提醒,如果你的 redis 持久化手段中有 aof,那么在 server 故障失效后再次启动前,需要检测 aof 文件的完整性。

AOF 默认关闭,开启方法,修改配置文件 reds.conf:appendonly yes

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
##此选项为aof功能的开关,默认为“no”,可以通过“yes”来开启aof功能  
##只有在“yes”下,aof重写/文件同步等特性才会生效
appendonly yes

##指定aof文件名称
appendfilename appendonly.aof

##指定aof操作中文件同步策略,有三个合法值:always everysec no,默认为everysec
appendfsync everysec
##在aof-rewrite期间,appendfsync是否暂缓文件同步,"no"表示“不暂缓”,“yes”表示“暂缓”,默认为“no”
no-appendfsync-on-rewrite no

##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite,默认“64mb”,建议“512mb”
auto-aof-rewrite-min-size 64mb

##相对于“上一次”rewrite,本次rewrite触发时aof文件应该增长的百分比。
##每一次rewrite之后,redis都会记录下此时“新aof”文件的大小(例如A),那么当aof文件增长到A*(1 + p)之后
##触发下一次rewrite,每一次aof记录的添加,都会检测当前aof文件的尺寸。
auto-aof-rewrite-percentage 100

AOF 是文件操作,对于变更操作比较密集的 server,那么必将造成磁盘 I/O 的负荷加重;此外 linux 对文件操作采取了“延迟写入”手段,即并非每次 write 操作都会触发实际磁盘操作,而是进入了 buffer 中,当 buffer 数据达到阀值时触发实际写入(也有其他时机),这是 linux 对文件系统的优化,但是这却有可能带来隐患,如果 buffer 没有刷新到磁盘,此时物理机器失效(比如断电),那么有可能导致最后一条或者多条 aof 记录的丢失。通过上述配置文件,可以得知 redis 提供了 3 中 aof 记录同步选项:

  • always:每一条 aof 记录都立即同步到文件,这是最安全的方式,也以为更多的磁盘操作和阻塞延迟,是 I/O 开支较大。
  • everysec:每秒同步一次,性能和安全都比较中庸的方式,也是 redis 推荐的方式。如果遇到物理服务器故障,有可能导致最近一秒内 aof 记录丢失(可能为部分丢失)。
  • no:redis 并不直接调用文件同步,而是交给操作系统来处理,操作系统可以根据 buffer 填充情况/通道空闲时间等择机触发同步;这是一种普通的文件操作方式。性能较好,在物理服务器故障时,数据丢失量会因 OS 配置有关。

其实,我们可以选择的太少,everysec 是最佳的选择。如果你非常在意每个数据都极其可靠,建议你选择一款“关系性数据库”吧。

AOF 文件会不断增大,它的大小直接影响“故障恢复”的时间,而且 AOF 文件中历史操作是可以丢弃的。AOF rewrite 操作就是“压缩” AOF 文件的过程,当然 redis 并没有采用“基于原 aof 文件”来重写的方式,而是采取了类似 snapshot 的方式:基于 copy-on-write,全量遍历内存中数据,然后逐个序列到 aof 文件中。因此 AOF rewrite 能够正确反应当前内存数据的状态,这正是我们所需要的;rewrite 过程中,对于新的变更操作将仍然被写入到原 AOF 文件中,同时这些新的变更操作也会被 redis 收集起来(buffer,copy-on-write 方式下,最极端的可能是所有的 key 都在此期间被修改,将会耗费 2 倍内存),当内存数据被全部写入到新的 aof 文件之后,收集的新的变更操作也将会一并追加到新的 aof 文件中,此后将会重命名新的 aof 文件为 appendonly.aof,此后所有的操作都将被写入新的 aof 文件。如果在 rewrite 过程中,出现故障,将不会影响原 AOF 文件的正常工作,只有当 rewrite 完成之后才会切换文件,因为 rewrite 过程是比较可靠的。

触发 rewrite 的时机可以通过配置文件来声明,同时 redis 中可以通过 bgrewriteaof 指令人工干预。

1
redis-cli -h ip -p port bgrewriteaof

因为 rewrite 操作/ aof 记录同步/ snapshot 都消耗磁盘 I/O,redis 采取了“schedule”策略:无论是“人工干预”还是系统触发,snapshot 和 rewrite 需要逐个被执行。

AOF rewrite 过程并不阻塞客户端请求。系统会开启一个子进程来完成。

总结:

AOF 和 RDB 各有优缺点,这是有它们各自的特点所决定:

  1. AOF 更加安全,可以将数据更加及时的同步到文件中,但是 AOF 需要较多的磁盘 I/O 开支,AOF 文件尺寸较大,文件内容恢复数度相对较慢。
  2. snapshot,安全性较差,它是“正常时期”数据备份以及 master-slave 数据同步的最佳手段,文件尺寸较小,恢复数度较快。

可以通过配置文件来指定它们中的一种,或者同时使用它们(不建议同时使用),或者全部禁用,在架构良好的环境中,master 通常使用 AOF,slave 使用 snapshot,主要原因是 master 需要首先确保数据完整性,它作为数据备份的第一选择;slave 提供只读服务(目前 slave 只能提供读取服务),它的主要目的就是快速响应客户端 read 请求;但是如果你的 redis 运行在网络稳定性差/物理环境糟糕情况下,建议你 master 和 slave 均采取 AOF,这个在 master 和 slave 角色切换时,可以减少“人工数据备份”/“人工引导数据恢复”的时间成本;如果你的环境一切非常良好,且服务需要接收密集性的 write 操作,那么建议 master 采取 snapshot,而 slave 采用 AOF。