diff --git a/404.html b/404.html new file mode 100644 index 00000000..b062c6e3 --- /dev/null +++ b/404.html @@ -0,0 +1,20 @@ + + + + + + DB-TUTORIAL + + + + + + + + + + +
404
看来我们的链接坏掉了~
返回首页
+ + + diff --git a/archives/index.html b/archives/index.html new file mode 100644 index 00000000..0b79a5e7 --- /dev/null +++ b/archives/index.html @@ -0,0 +1,223 @@ + + + + + + 归档 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL

+ 归档 +

+ 总共 87 篇文章 +
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/assets/css/0.styles.77b73934.css b/assets/css/0.styles.77b73934.css new file mode 100644 index 00000000..1dfbe2e4 --- /dev/null +++ b/assets/css/0.styles.77b73934.css @@ -0,0 +1 @@ +@import url(//at.alicdn.com/t/font_1678482_4tbhmh589x.css);.code-copy{color:#aaa;fill:#aaa;font-size:14px;display:inline-block;cursor:pointer}div[class*=aside-code] aside .code-copy,div[class*=language-] pre .code-copy{position:absolute;z-index:1000;top:7px;right:35px;opacity:0;font-size:16px}div[class*=aside-code] aside:hover .code-copy,div[class*=language-] pre:hover .code-copy{opacity:1}.content pre,.content pre[class*=language-]{overflow-y:hidden}div[class*=language-] pre,div[class*=language-] pre[class*=language-]{position:static!important}div[class~=language-text]:before{content:"text"}div[class~=language-yml]:before{content:"yml"}div[class*=language-] pre{-webkit-user-select:text;-moz-user-select:text;user-select:text}p code{-webkit-user-select:all;-moz-user-select:all;user-select:all}@keyframes message-move-in{0%{opacity:0;transform:translateY(-100%)}to{opacity:1;transform:translateY(0)}}#message-container .message.move-in{animation:message-move-in .3s ease-in-out}@keyframes message-move-out{0%{opacity:1;transform:translateY(0)}to{opacity:0;transform:translateY(-100%)}}#message-container .message.move-out{animation:message-move-out .3s ease-in-out;animation-fill-mode:forwards}#message-container .message{background:#fff;margin:10px 0;padding:0 10px;height:40px;box-shadow:0 0 10px 0 #ccc;font-size:14px;border-radius:3px;display:flex;align-items:center;transition:height .2s ease-in-out,margin .2s ease-in-out}#message-container{position:fixed;left:0;top:100px;right:0;display:flex;flex-direction:column;align-items:center}#message-container .message .text{color:#333;padding:0 20px 0 5px}.theme-code-block[data-v-4f1e9d0c]{display:none}.theme-code-block__active[data-v-4f1e9d0c]{display:block}.theme-code-block>pre[data-v-4f1e9d0c]{background-color:orange}@media (max-width:419px){.theme-code-group div[class*=language-][data-v-4f1e9d0c]{margin:0}}.theme-mode-light[data-v-2f5f1757]{--bodyBg:#f4f4f4;--customBlockBg:#f1f1f1;--textColor:#00323c;--borderColor:rgba(0,0,0,0.12)}.theme-mode-dark[data-v-2f5f1757]{--bodyBg:#27272b;--customBlockBg:#27272b;--textColor:#9b9baa;--borderColor:#30363d}.theme-mode-read[data-v-2f5f1757]{--bodyBg:#ececcc;--customBlockBg:#ececcc;--textColor:#704214;--textLightenColor:#963}.theme-style-line.theme-mode-light[data-v-2f5f1757]{--bodyBg:#fff}.theme-style-line.theme-mode-dark[data-v-2f5f1757]{--bodyBg:#1e1e22}.theme-style-line.theme-mode-read[data-v-2f5f1757]{--bodyBg:#f5f5d5}.theme-mode-light[data-v-2f5f1757]{--bodyBg:#fff;--mainBg:#fff;--sidebarBg:hsla(0,0%,100%,0.8);--blurBg:hsla(0,0%,100%,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#f6f6f6;--codeColor:#525252}.theme-mode-light code[class*=language-][data-v-2f5f1757],.theme-mode-light pre[class*=language-][data-v-2f5f1757]{color:#000;background:none;text-shadow:0 1px #fff;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-light code[class*=language-][data-v-2f5f1757]::-moz-selection,.theme-mode-light code[class*=language-][data-v-2f5f1757] ::-moz-selection,.theme-mode-light pre[class*=language-][data-v-2f5f1757]::-moz-selection,.theme-mode-light pre[class*=language-][data-v-2f5f1757] ::-moz-selection{text-shadow:none;background:#b3d4fc}.theme-mode-light code[class*=language-][data-v-2f5f1757]::selection,.theme-mode-light code[class*=language-][data-v-2f5f1757] ::selection,.theme-mode-light pre[class*=language-][data-v-2f5f1757]::selection,.theme-mode-light pre[class*=language-][data-v-2f5f1757] ::selection{text-shadow:none;background:#b3d4fc}@media print{.theme-mode-light code[class*=language-][data-v-2f5f1757],.theme-mode-light pre[class*=language-][data-v-2f5f1757]{text-shadow:none}}.theme-mode-light pre[class*=language-][data-v-2f5f1757]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-light :not(pre)>code[class*=language-][data-v-2f5f1757],.theme-mode-light pre[class*=language-][data-v-2f5f1757]{background:#f5f2f0}.theme-mode-light :not(pre)>code[class*=language-][data-v-2f5f1757]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-light .token.cdata[data-v-2f5f1757],.theme-mode-light .token.comment[data-v-2f5f1757],.theme-mode-light .token.doctype[data-v-2f5f1757],.theme-mode-light .token.prolog[data-v-2f5f1757]{color:#708090}.theme-mode-light .token.punctuation[data-v-2f5f1757]{color:#999}.theme-mode-light .namespace[data-v-2f5f1757]{opacity:.7}.theme-mode-light .token.boolean[data-v-2f5f1757],.theme-mode-light .token.constant[data-v-2f5f1757],.theme-mode-light .token.deleted[data-v-2f5f1757],.theme-mode-light .token.number[data-v-2f5f1757],.theme-mode-light .token.property[data-v-2f5f1757],.theme-mode-light .token.symbol[data-v-2f5f1757],.theme-mode-light .token.tag[data-v-2f5f1757]{color:#905}.theme-mode-light .token.attr-name[data-v-2f5f1757],.theme-mode-light .token.builtin[data-v-2f5f1757],.theme-mode-light .token.char[data-v-2f5f1757],.theme-mode-light .token.inserted[data-v-2f5f1757],.theme-mode-light .token.selector[data-v-2f5f1757],.theme-mode-light .token.string[data-v-2f5f1757]{color:#690}.theme-mode-light .language-css .token.string[data-v-2f5f1757],.theme-mode-light .style .token.string[data-v-2f5f1757],.theme-mode-light .token.entity[data-v-2f5f1757],.theme-mode-light .token.operator[data-v-2f5f1757],.theme-mode-light .token.url[data-v-2f5f1757]{color:#9a6e3a;background:hsla(0,0%,100%,.5)}.theme-mode-light .token.atrule[data-v-2f5f1757],.theme-mode-light .token.attr-value[data-v-2f5f1757],.theme-mode-light .token.keyword[data-v-2f5f1757]{color:#07a}.theme-mode-light .token.class-name[data-v-2f5f1757],.theme-mode-light .token.function[data-v-2f5f1757]{color:#dd4a68}.theme-mode-light .token.important[data-v-2f5f1757],.theme-mode-light .token.regex[data-v-2f5f1757],.theme-mode-light .token.variable[data-v-2f5f1757]{color:#e90}.theme-mode-light .token.bold[data-v-2f5f1757],.theme-mode-light .token.important[data-v-2f5f1757]{font-weight:700}.theme-mode-light .token.italic[data-v-2f5f1757]{font-style:italic}.theme-mode-light .token.entity[data-v-2f5f1757]{cursor:help}.theme-mode-light div[class*=language-] .highlight-lines .highlighted[data-v-2f5f1757],.theme-mode-light div[class*=language-].line-numbers-mode .highlight-lines .highlighted[data-v-2f5f1757]:before{background-color:hsla(0,0%,78.4%,.4)}.theme-mode-dark[data-v-2f5f1757]{--bodyBg:#1e1e22;--mainBg:#1e1e22;--sidebarBg:rgba(30,30,34,0.8);--blurBg:rgba(30,30,34,0.8);--textColor:#8c8c96;--textLightenColor:#0085ad;--borderColor:#2c2c3a;--codeBg:#252526;--codeColor:#fff}.theme-mode-dark code[class*=language-][data-v-2f5f1757],.theme-mode-dark pre[class*=language-][data-v-2f5f1757]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-dark pre[class*=language-][data-v-2f5f1757]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-dark :not(pre)>code[class*=language-][data-v-2f5f1757],.theme-mode-dark pre[class*=language-][data-v-2f5f1757]{background:#2d2d2d}.theme-mode-dark :not(pre)>code[class*=language-][data-v-2f5f1757]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-dark .token.block-comment[data-v-2f5f1757],.theme-mode-dark .token.cdata[data-v-2f5f1757],.theme-mode-dark .token.comment[data-v-2f5f1757],.theme-mode-dark .token.doctype[data-v-2f5f1757],.theme-mode-dark .token.prolog[data-v-2f5f1757]{color:#999}.theme-mode-dark .token.punctuation[data-v-2f5f1757]{color:#ccc}.theme-mode-dark .token.attr-name[data-v-2f5f1757],.theme-mode-dark .token.deleted[data-v-2f5f1757],.theme-mode-dark .token.namespace[data-v-2f5f1757],.theme-mode-dark .token.tag[data-v-2f5f1757]{color:#e2777a}.theme-mode-dark .token.function-name[data-v-2f5f1757]{color:#6196cc}.theme-mode-dark .token.boolean[data-v-2f5f1757],.theme-mode-dark .token.function[data-v-2f5f1757],.theme-mode-dark .token.number[data-v-2f5f1757]{color:#f08d49}.theme-mode-dark .token.class-name[data-v-2f5f1757],.theme-mode-dark .token.constant[data-v-2f5f1757],.theme-mode-dark .token.property[data-v-2f5f1757],.theme-mode-dark .token.symbol[data-v-2f5f1757]{color:#f8c555}.theme-mode-dark .token.atrule[data-v-2f5f1757],.theme-mode-dark .token.builtin[data-v-2f5f1757],.theme-mode-dark .token.important[data-v-2f5f1757],.theme-mode-dark .token.keyword[data-v-2f5f1757],.theme-mode-dark .token.selector[data-v-2f5f1757]{color:#cc99cd}.theme-mode-dark .token.attr-value[data-v-2f5f1757],.theme-mode-dark .token.char[data-v-2f5f1757],.theme-mode-dark .token.regex[data-v-2f5f1757],.theme-mode-dark .token.string[data-v-2f5f1757],.theme-mode-dark .token.variable[data-v-2f5f1757]{color:#7ec699}.theme-mode-dark .token.entity[data-v-2f5f1757],.theme-mode-dark .token.operator[data-v-2f5f1757],.theme-mode-dark .token.url[data-v-2f5f1757]{color:#67cdcc}.theme-mode-dark .language-css .token.string[data-v-2f5f1757],.theme-mode-dark .style .token.string[data-v-2f5f1757],.theme-mode-dark .token.entity[data-v-2f5f1757],.theme-mode-dark .token.operator[data-v-2f5f1757],.theme-mode-dark .token.url[data-v-2f5f1757]{background:none}.theme-mode-dark .token.bold[data-v-2f5f1757],.theme-mode-dark .token.important[data-v-2f5f1757]{font-weight:700}.theme-mode-dark .token.italic[data-v-2f5f1757]{font-style:italic}.theme-mode-dark .token.entity[data-v-2f5f1757]{cursor:help}.theme-mode-dark .token.inserted[data-v-2f5f1757]{color:green}.theme-mode-read[data-v-2f5f1757]{--bodyBg:#f5f5d5;--mainBg:#f5f5d5;--sidebarBg:rgba(245,245,213,0.8);--blurBg:rgba(245,245,213,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#282c34;--codeColor:#fff}.theme-mode-read code[class*=language-][data-v-2f5f1757],.theme-mode-read pre[class*=language-][data-v-2f5f1757]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-read pre[class*=language-][data-v-2f5f1757]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-read :not(pre)>code[class*=language-][data-v-2f5f1757],.theme-mode-read pre[class*=language-][data-v-2f5f1757]{background:#2d2d2d}.theme-mode-read :not(pre)>code[class*=language-][data-v-2f5f1757]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-read .token.block-comment[data-v-2f5f1757],.theme-mode-read .token.cdata[data-v-2f5f1757],.theme-mode-read .token.comment[data-v-2f5f1757],.theme-mode-read .token.doctype[data-v-2f5f1757],.theme-mode-read .token.prolog[data-v-2f5f1757]{color:#999}.theme-mode-read .token.punctuation[data-v-2f5f1757]{color:#ccc}.theme-mode-read .token.attr-name[data-v-2f5f1757],.theme-mode-read .token.deleted[data-v-2f5f1757],.theme-mode-read .token.namespace[data-v-2f5f1757],.theme-mode-read .token.tag[data-v-2f5f1757]{color:#e2777a}.theme-mode-read .token.function-name[data-v-2f5f1757]{color:#6196cc}.theme-mode-read .token.boolean[data-v-2f5f1757],.theme-mode-read .token.function[data-v-2f5f1757],.theme-mode-read .token.number[data-v-2f5f1757]{color:#f08d49}.theme-mode-read .token.class-name[data-v-2f5f1757],.theme-mode-read .token.constant[data-v-2f5f1757],.theme-mode-read .token.property[data-v-2f5f1757],.theme-mode-read .token.symbol[data-v-2f5f1757]{color:#f8c555}.theme-mode-read .token.atrule[data-v-2f5f1757],.theme-mode-read .token.builtin[data-v-2f5f1757],.theme-mode-read .token.important[data-v-2f5f1757],.theme-mode-read .token.keyword[data-v-2f5f1757],.theme-mode-read .token.selector[data-v-2f5f1757]{color:#cc99cd}.theme-mode-read .token.attr-value[data-v-2f5f1757],.theme-mode-read .token.char[data-v-2f5f1757],.theme-mode-read .token.regex[data-v-2f5f1757],.theme-mode-read .token.string[data-v-2f5f1757],.theme-mode-read .token.variable[data-v-2f5f1757]{color:#7ec699}.theme-mode-read .token.entity[data-v-2f5f1757],.theme-mode-read .token.operator[data-v-2f5f1757],.theme-mode-read .token.url[data-v-2f5f1757]{color:#67cdcc}.theme-mode-read .language-css .token.string[data-v-2f5f1757],.theme-mode-read .style .token.string[data-v-2f5f1757],.theme-mode-read .token.entity[data-v-2f5f1757],.theme-mode-read .token.operator[data-v-2f5f1757],.theme-mode-read .token.url[data-v-2f5f1757]{background:none}.theme-mode-read .token.bold[data-v-2f5f1757],.theme-mode-read .token.important[data-v-2f5f1757]{font-weight:700}.theme-mode-read .token.italic[data-v-2f5f1757]{font-style:italic}.theme-mode-read .token.entity[data-v-2f5f1757]{cursor:help}.theme-mode-read .token.inserted[data-v-2f5f1757]{color:green}.theme-code-group[data-v-2f5f1757],.theme-code-group__nav[data-v-2f5f1757]{background-color:var(--codeBg);padding-bottom:22px;border-radius:6px;padding-left:10px;padding-top:10px}.theme-code-group__nav[data-v-2f5f1757]{margin-bottom:-35px}.theme-code-group__ul[data-v-2f5f1757]{margin:auto 0;padding-left:0;display:inline-flex;list-style:none}.theme-code-group__li[data-v-2f5f1757],.theme-code-group__nav-tab[data-v-2f5f1757]{border:0;padding:5px;cursor:pointer;background-color:transparent;font-size:.85em;line-height:1.4;color:var(--codeColor);font-weight:600;opacity:.85}.theme-code-group__nav-tab-active[data-v-2f5f1757]{border-bottom:1px solid #11a8cd;opacity:1}.pre-blank[data-v-2f5f1757]{color:#11a8cd}body .theme-vdoing-content code{color:var(--textLightenColor);padding:.25rem .5rem;margin:0;font-size:.9em;background-color:hsla(0,0%,39.2%,.08);border-radius:3px}body .theme-vdoing-content code .token.deleted{color:#ec5975}body .theme-vdoing-content code .token.inserted{color:#11a8cd}body .theme-vdoing-content pre,body .theme-vdoing-content pre[class*=language-]{line-height:1.4;padding:1.25rem 1.5rem;margin:.85rem 0;background-color:#282c34;border-radius:6px;overflow:auto}body .theme-vdoing-content pre[class*=language-] code,body .theme-vdoing-content pre code{color:var(--codeColor);padding:0;background-color:transparent;border-radius:0}div[class*=language-]{position:relative;background-color:var(--codeBg);border-radius:6px}div[class*=language-] .highlight-lines{-webkit-user-select:none;user-select:none;padding-top:1.3rem;position:absolute;top:0;left:0;width:100%;line-height:1.4}div[class*=language-] .highlight-lines .highlighted{background-color:rgba(0,0,0,.3)}div[class*=language-] pre,div[class*=language-] pre[class*=language-]{background:transparent;position:relative!important;z-index:1}div[class*=language-]:before{position:absolute;z-index:3;top:.8em;right:1em;font-size:.8rem;color:hsla(0,0%,58.8%,.7)}div[class*=language-]:not(.line-numbers-mode) .line-numbers-wrapper{display:none}div[class*=language-].line-numbers-mode .highlight-lines .highlighted{position:relative}div[class*=language-].line-numbers-mode .highlight-lines .highlighted:before{content:" ";position:absolute;z-index:3;left:0;top:0;display:block;width:2.5rem;height:100%;background-color:rgba(0,0,0,.3)}div[class*=language-].line-numbers-mode pre{padding-left:3.5rem;vertical-align:middle}div[class*=language-].line-numbers-mode .line-numbers-wrapper{position:absolute;top:0;width:2.5rem;text-align:center;color:hsla(0,0%,49.8%,.5);padding:1.25rem 0;line-height:1.4}div[class*=language-].line-numbers-mode .line-numbers-wrapper br{-webkit-user-select:none;user-select:none}div[class*=language-].line-numbers-mode .line-numbers-wrapper .line-number{position:relative;z-index:4;-webkit-user-select:none;user-select:none;font-size:.85em}div[class*=language-].line-numbers-mode:after{content:"";position:absolute;z-index:2;top:0;left:0;width:2.5rem;height:100%;border-radius:6px 0 0 6px;border-right:1px solid var(--borderColor);background-color:var(--codeBg)}div[class~=language-js]:before{content:"js"}div[class~=language-ts]:before{content:"ts"}div[class~=language-html]:before{content:"html"}div[class~=language-md]:before{content:"md"}div[class~=language-vue]:before{content:"vue"}div[class~=language-css]:before{content:"css"}div[class~=language-sass]:before{content:"sass"}div[class~=language-scss]:before{content:"scss"}div[class~=language-less]:before{content:"less"}div[class~=language-stylus]:before{content:"stylus"}div[class~=language-go]:before{content:"go"}div[class~=language-java]:before{content:"java"}div[class~=language-c]:before{content:"c"}div[class~=language-sh]:before{content:"sh"}div[class~=language-yaml]:before{content:"yaml"}div[class~=language-py]:before{content:"py"}div[class~=language-docker]:before{content:"docker"}div[class~=language-dockerfile]:before{content:"dockerfile"}div[class~=language-makefile]:before{content:"makefile"}div[class~=language-javascript]:before{content:"js"}div[class~=language-typescript]:before{content:"ts"}div[class~=language-markup]:before{content:"html"}div[class~=language-markdown]:before{content:"md"}div[class~=language-json]:before{content:"json"}div[class~=language-ruby]:before{content:"rb"}div[class~=language-python]:before{content:"py"}div[class~=language-bash]:before{content:"sh"}div[class~=language-php]:before{content:"php"}.custom-block .custom-block-title{font-weight:600;margin-bottom:.2rem}.custom-block p{margin:0}.custom-block.danger,.custom-block.note,.custom-block.tip,.custom-block.warning{padding:.5rem 1.5rem;border-left-width:.5rem;border-left-style:solid;margin:1rem 0}.custom-block.tip{background-color:#f3f5f7;border-color:#42b983;color:#215d42}.custom-block.warning{background-color:#fff7d0;border-color:#e7c000;color:#6b5900}.custom-block.warning .custom-block-title{color:#b29400}.custom-block.warning a{color:var(--textColor)}.custom-block.danger{background-color:#ffe6e6;border-color:#c00;color:#4d0000}.custom-block.danger .custom-block-title{color:#900}.custom-block.danger a{color:var(--textColor)}.custom-block.note{background-color:#e8f5fa;border-color:#157bae;color:#0d4a68}.custom-block.right{color:var(--textColor);font-size:.9rem;text-align:right}.custom-block.theorem{margin:1rem 0;padding:.8rem 1.5rem;border-radius:2px;background-color:var(--customBlockBg)}.custom-block.theorem .title{font-weight:700;margin:.5rem 0}.custom-block.details{display:block;position:relative;border-radius:2px;margin:1em 0;padding:1.6em;background-color:var(--customBlockBg)}.custom-block.details p{margin:.8rem 0}.custom-block.details h4{margin-top:0}.custom-block.details figure:last-child,.custom-block.details p:last-child{margin-bottom:0;padding-bottom:0}.custom-block.details summary{outline:none;cursor:pointer}.custom-block.details summary:hover{color:#11a8cd}.theme-mode-dark .custom-block.warning{background-color:rgba(255,247,208,.2);color:#e7c000}.theme-mode-dark .custom-block.warning .custom-block-title{color:#ffdc2f}.theme-mode-dark .custom-block.tip{background-color:rgba(243,245,247,.2);color:#42b983}.theme-mode-dark .custom-block.danger{background-color:rgba(255,230,230,.4);color:maroon}.theme-mode-dark .custom-block.danger a{color:#11a8cd}.theme-mode-dark .custom-block.note{background-color:rgba(243,245,247,.2);color:#157bae}.arrow{display:inline-block;width:0;height:0}.arrow.up{border-bottom:6px solid #ccc}.arrow.down,.arrow.up{border-left:4px solid transparent;border-right:4px solid transparent}.arrow.down{border-top:6px solid #ccc}.arrow.right{border-left:6px solid #ccc}.arrow.left,.arrow.right{border-top:4px solid transparent;border-bottom:4px solid transparent}.arrow.left{border-right:6px solid #ccc}.theme-vdoing-content:not(.custom){max-width:860px}.table-of-contents .badge{vertical-align:middle}.center-container{text-align:center}.center-container>h1,.center-container>h2,.center-container>h3,.center-container>h4,.center-container>h5,.center-container>h6{margin-top:-3.1rem;padding-top:4.6rem;margin-bottom:0}.center-container>h1 a.header-anchor,.center-container>h2 a.header-anchor,.center-container>h3 a.header-anchor,.center-container>h4 a.header-anchor,.center-container>h5 a.header-anchor,.center-container>h6 a.header-anchor{float:none;padding-right:0;margin-left:-.9rem}.cardListContainer{margin:.7rem 0}.cardListContainer>:not(.card-list){display:none}.cardListContainer .card-list{margin:-.35rem;display:flex;flex-wrap:wrap;align-items:flex-start}.cardListContainer .card-list .card-item{width:calc(33.33333% - .7rem);margin:.35rem;background:var(--bodyBg);border-radius:3px;color:var(--textColor);display:flex;box-shadow:1px 1px 2px 0 rgba(0,0,0,.06);transition:all .4s}.cardListContainer .card-list .card-item:hover{text-decoration:none;box-shadow:0 10px 20px -10px var(--randomColor,rgba(0,0,0,.15));transform:translateY(-3px) scale(1.01)}.cardListContainer .card-list .card-item:hover img{box-shadow:3px 2px 7px rgba(0,0,0,.15)}.cardListContainer .card-list .card-item:hover div p{text-shadow:3px 2px 5px rgba(0,0,0,.15)}.cardListContainer .card-list .card-item img{width:60px;height:60px;border-radius:50%;border:2px solid #fff;margin:1rem 0 1rem 1rem;box-shadow:3px 2px 5px rgba(0,0,0,.08);transition:all .4s}.cardListContainer .card-list .card-item div{flex:1;display:inline-block;float:right;padding:1rem 0}.cardListContainer .card-list .card-item div p{margin:0;padding:0 1rem;transition:text-shadow .4s;text-align:center}.cardListContainer .card-list .card-item div .name{margin:.2rem 0 .3rem}.cardListContainer .card-list .card-item div .desc{font-size:.8rem;line-height:1.1rem;opacity:.8;margin-bottom:.2rem}.cardListContainer .card-list .card-item.row-1{width:calc(100% - .7rem)}.cardListContainer .card-list .card-item.row-1 img{margin-left:2rem}.cardListContainer .card-list .card-item.row-2{width:calc(50% - .7rem)}.cardListContainer .card-list .card-item.row-2 img{margin-left:1.5rem}.cardListContainer .card-list .card-item.row-3{width:calc(33.33333% - .7rem)}.cardListContainer .card-list .card-item.row-4{width:calc(25% - .7rem)}.cardImgListContainer{margin:1rem 0}.cardImgListContainer>:not(.card-list){display:none}.cardImgListContainer .card-list{margin:-.5rem;display:flex;flex-wrap:wrap;align-items:flex-start}.cardImgListContainer .card-list .card-item{width:calc(33.33333% - 1rem);margin:.5rem;background:var(--mainBg);border:1px solid rgba(0,0,0,.1);box-sizing:border-box;border-radius:3px;overflow:hidden;color:var(--textColor);box-shadow:2px 2px 10px rgba(0,0,0,.04);display:flex;flex-direction:column;justify-content:flex-start;align-items:stretch;align-content:stretch;transition:all .4s}.cardImgListContainer .card-list .card-item:hover{box-shadow:1px 1px 20px rgba(0,0,0,.1);transform:translateY(-3px)}.cardImgListContainer .card-list .card-item .box-img{overflow:hidden;position:relative;background:#eee}.cardImgListContainer .card-list .card-item .box-img img{display:block;width:100%;height:100%;transition:all .3s}.cardImgListContainer .card-list .card-item a{color:var(--textColor);transition:color .3s}.cardImgListContainer .card-list .card-item a:hover{text-decoration:none}.cardImgListContainer .card-list .card-item .box-info{padding:.8rem 1rem}.cardImgListContainer .card-list .card-item .box-info p{margin:0}.cardImgListContainer .card-list .card-item .box-info .desc{margin-top:.3rem;opacity:.8;font-size:.9rem;line-height:1.1rem;overflow:hidden;white-space:normal;text-overflow:ellipsis;display:-webkit-box;-webkit-box-orient:vertical}.cardImgListContainer .card-list .card-item .box-footer{overflow:hidden;padding:.8rem 1rem;border-top:1px solid rgba(0,0,0,.1)}.cardImgListContainer .card-list .card-item .box-footer img{width:1.8rem;height:1.8rem;border-radius:50%;float:left}.cardImgListContainer .card-list .card-item .box-footer span{line-height:1.8rem;float:left;margin-left:.6rem;font-size:.8rem}.cardImgListContainer .card-list .card-item.row-1{width:calc(100% - 1rem)}.cardImgListContainer .card-list .card-item.row-2{width:calc(50% - 1rem)}.cardImgListContainer .card-list .card-item.row-3{width:calc(33.33333% - 1rem)}.cardImgListContainer .card-list .card-item.row-4{width:calc(25% - 1rem)}.theme-mode-dark .cardImgListContainer .card-list .card-item,.theme-mode-dark .cardImgListContainer .card-list .card-item .box-footer{border-color:var(--borderColor)}@media (max-width:900px){.cardListContainer .card-list .card-item.row-4{width:calc(33.33333% - .7rem)}.cardImgListContainer .card-list .card-item.row-4{width:calc(33.33333% - 1rem)}}@media (max-width:720px){.cardListContainer .card-list .card-item.row-3,.cardListContainer .card-list .card-item.row-4{width:calc(50% - .7rem)}.cardListContainer .card-list .card-item.row-3 img,.cardListContainer .card-list .card-item.row-4 img{margin-left:1.5rem}.cardImgListContainer .card-list .card-item.row-3,.cardImgListContainer .card-list .card-item.row-4{width:calc(50% - 1rem)}}@media (max-width:500px){.cardListContainer .card-list .card-item.row-1,.cardListContainer .card-list .card-item.row-2,.cardListContainer .card-list .card-item.row-3,.cardListContainer .card-list .card-item.row-4{width:calc(100% - .7rem)}.cardListContainer .card-list .card-item.row-1 img,.cardListContainer .card-list .card-item.row-2 img,.cardListContainer .card-list .card-item.row-3 img,.cardListContainer .card-list .card-item.row-4 img{margin-left:1.5rem}.cardImgListContainer .card-list .card-item.row-1,.cardImgListContainer .card-list .card-item.row-2,.cardImgListContainer .card-list .card-item.row-3,.cardImgListContainer .card-list .card-item.row-4{width:calc(100% - 1rem)}}body,html{padding:0;margin:0}body{font-family:-apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Oxygen,Ubuntu,Cantarell,Fira Sans,Droid Sans,Helvetica Neue,sans-serif;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;-webkit-tap-highlight-color:transparent;font-size:16px;color:#2c3e50;background:var(--bodyBg)}a,button,input{outline:none;-webkit-tap-highlight-color:rgba(255,255,255,0);-webkit-focus-ring-color:transparent}@media (min-width:719px){::-webkit-scrollbar{width:6px;height:5px}::-webkit-scrollbar-track-piece{background-color:rgba(0,0,0,.15);-webkit-border-radius:3px}::-webkit-scrollbar-thumb:vertical{height:5px;background-color:rgba(0,0,0,.28);-webkit-border-radius:3px}::-webkit-scrollbar-thumb:horizontal{width:5px;background-color:rgba(0,0,0,.28);-webkit-border-radius:3px}}.card-box{border-radius:5px;background:var(--mainBg);box-shadow:0 0 4px 0 rgba(0,0,0,.1);transition:box-shadow .5s}.card-box:hover{box-shadow:0 1px 15px 0 rgba(0,0,0,.1)}@media (max-width:719px){.theme-style-line{margin-left:-1px;margin-right:-1px}}.theme-style-line .card-box{box-shadow:0 0;border:1px solid var(--borderColor)}.blur{-webkit-backdrop-filter:saturate(200%) blur(20px);backdrop-filter:saturate(200%) blur(20px)}.custom-page{min-height:calc(100vh - 3.6rem);padding-top:3.6rem;padding-bottom:.9rem}.custom-page .theme-vdoing-wrapper{margin:0 auto}body .search-box input{background-color:transparent;color:var(--textColor);border:1px solid var(--borderColor,#ccc)}@media (max-width:959px){body .search-box input{border-color:transparent}}.page{transition:padding .2s ease;padding-left:.8rem}.navbar{position:fixed;z-index:20;top:0;left:0;right:0;height:3.6rem;background-color:var(--blurBg);box-sizing:border-box;box-shadow:0 2px 5px rgba(0,0,0,.06)}.sidebar-mask{top:0;width:100vw;height:100vh}.sidebar-hover-trigger,.sidebar-mask{position:fixed;z-index:12;left:0;display:none}.sidebar-hover-trigger{top:8.1rem;bottom:0;width:24px}.sidebar{font-size:16px;background-color:var(--sidebarBg);width:18rem;position:fixed;z-index:13;margin:0;top:3.6rem;left:0;bottom:0;box-sizing:border-box;border-right:1px solid var(--borderColor);overflow-y:auto;transform:translateX(-100%);transition:transform .2s}@media (max-width:719px){.sidebar{background-color:var(--mainBg)}}.theme-vdoing-content:not(.custom){word-wrap:break-word}.theme-vdoing-content:not(.custom) a:hover{text-decoration:underline}.theme-vdoing-content:not(.custom) p.demo{padding:1rem 1.5rem;border:1px solid #ddd;border-radius:4px}.theme-vdoing-content:not(.custom) img{max-width:100%}.theme-vdoing-content.custom{padding:0;margin:0}.theme-vdoing-content.custom img{max-width:100%}a{font-weight:500;text-decoration:none}a,p a code{color:#11a8cd}p a code{font-weight:400}kbd{background:#eee;border:.15rem solid #ddd;border-bottom:.25rem solid #ddd;border-radius:.15rem;padding:0 .15em}blockquote{font-size:1rem;opacity:.75;border-left:.2rem solid hsla(0,0%,39.2%,.3);margin:1rem 0;padding:.25rem 0 .25rem 1rem}blockquote>p{margin:0}ol,ul{padding-left:1.2em}strong{font-weight:600}h1,h2,h3,h4,h5,h6{font-weight:600;line-height:1.25}.theme-vdoing-content:not(.custom)>h1,.theme-vdoing-content:not(.custom)>h2,.theme-vdoing-content:not(.custom)>h3,.theme-vdoing-content:not(.custom)>h4,.theme-vdoing-content:not(.custom)>h5,.theme-vdoing-content:not(.custom)>h6{margin-top:-3.1rem;padding-top:4.6rem;margin-bottom:0}.theme-vdoing-content:not(.custom)>h1:first-child,.theme-vdoing-content:not(.custom)>h2:first-child,.theme-vdoing-content:not(.custom)>h3:first-child,.theme-vdoing-content:not(.custom)>h4:first-child,.theme-vdoing-content:not(.custom)>h5:first-child,.theme-vdoing-content:not(.custom)>h6:first-child{margin-bottom:1rem}.theme-vdoing-content:not(.custom)>h1:first-child+.custom-block,.theme-vdoing-content:not(.custom)>h1:first-child+p,.theme-vdoing-content:not(.custom)>h1:first-child+pre,.theme-vdoing-content:not(.custom)>h2:first-child+.custom-block,.theme-vdoing-content:not(.custom)>h2:first-child+p,.theme-vdoing-content:not(.custom)>h2:first-child+pre,.theme-vdoing-content:not(.custom)>h3:first-child+.custom-block,.theme-vdoing-content:not(.custom)>h3:first-child+p,.theme-vdoing-content:not(.custom)>h3:first-child+pre,.theme-vdoing-content:not(.custom)>h4:first-child+.custom-block,.theme-vdoing-content:not(.custom)>h4:first-child+p,.theme-vdoing-content:not(.custom)>h4:first-child+pre,.theme-vdoing-content:not(.custom)>h5:first-child+.custom-block,.theme-vdoing-content:not(.custom)>h5:first-child+p,.theme-vdoing-content:not(.custom)>h5:first-child+pre,.theme-vdoing-content:not(.custom)>h6:first-child+.custom-block,.theme-vdoing-content:not(.custom)>h6:first-child+p,.theme-vdoing-content:not(.custom)>h6:first-child+pre{margin-top:2rem}h1:focus .header-anchor,h1:hover .header-anchor,h2:focus .header-anchor,h2:hover .header-anchor,h3:focus .header-anchor,h3:hover .header-anchor,h4:focus .header-anchor,h4:hover .header-anchor,h5:focus .header-anchor,h5:hover .header-anchor,h6:focus .header-anchor,h6:hover .header-anchor{opacity:1}.theme-vdoing-content:not(.custom)>.custom-block:first-child,.theme-vdoing-content:not(.custom)>p:first-child,.theme-vdoing-content:not(.custom)>pre:first-child{margin-top:2rem}h1{font-size:1.9rem}.theme-vdoing-content:not(.custom)>h1:first-child{display:none}h2{font-size:1.5rem;padding-bottom:.3rem;border-bottom:1px solid var(--borderColor)}h3{font-size:1.35rem}.page h4{font-size:1.25rem}.page h5{font-size:1.15rem}.page h6{font-size:1.05rem}a.header-anchor{font-size:.85em;float:left;margin-left:-.87em;padding-right:.23em;margin-top:.125em;opacity:0}a.header-anchor:focus,a.header-anchor:hover{text-decoration:none}.line-number,code,kbd{font-family:source-code-pro,Menlo,Monaco,Consolas,Courier New,monospace}ol,p,ul{line-height:1.7}hr{border:0;border-top:1px solid var(--borderColor)}table{border-collapse:collapse;margin:1rem 0;overflow-x:auto;width:100%;display:inline-table}@media (max-width:719px){table{display:block}}tr{border-top:1px solid var(--borderColor)}tr:nth-child(2n){background-color:hsla(0,0%,58.8%,.1)}td,th{border:1px solid var(--borderColor);padding:.6em 1em}@media (max-width:719px){td,th{padding:.3em .5em}}td a,th a{word-break:break-all}.theme-container{color:var(--textColor);min-height:100vh}.theme-container.sidebar-open .sidebar-mask{display:block}.theme-container.no-navbar .theme-vdoing-content:not(.custom)>h1,.theme-container.no-navbar h2,.theme-container.no-navbar h3,.theme-container.no-navbar h4,.theme-container.no-navbar h5,.theme-container.no-navbar h6{margin-top:1.5rem;padding-top:0}.theme-container.no-navbar .sidebar{top:0}@media (min-width:720px){.theme-container.no-sidebar .sidebar{display:none}.theme-container.no-sidebar .page{padding-left:0}}@media (max-width:959px){.sidebar{font-size:15px}}@media (max-width:719px){.sidebar{width:17.099999999999998rem}}@media (min-width:720px) and (max-width:959px){.sidebar{width:16.2rem}.theme-container.sidebar-open .page{padding-left:17rem!important}}@media (max-width:719px){.sidebar{top:0;height:100vh;padding-top:3.6rem;transform:translateX(-100%);transition:transform .2s ease}.page{padding-left:0}.theme-container.sidebar-open .sidebar{transform:translateX(0)}.theme-container.sidebar-open .sidebar-mask{display:block}.theme-container.no-navbar .sidebar{padding-top:0}}@media (max-width:419px){h1{font-size:1.9rem}.theme-vdoing-content div[class*=language-]{margin:.85rem -1.5rem;border-radius:0}}@media (min-width:720px){.theme-container .sidebar-hover-trigger{display:block}.theme-container .sidebar-hover-trigger:hover~.sidebar,.theme-container:not(.sidebar-open) .sidebar-hover-trigger~.sidebar:hover{transform:translateX(0);z-index:100}.theme-container.sidebar-open .sidebar-mask{display:none}.theme-container.sidebar-open .sidebar{transform:translateX(0)}.theme-container.sidebar-open .sidebar-button{left:18rem}.theme-container.sidebar-open .page{padding-left:18.8rem;padding-right:.8rem}.theme-container.sidebar-open .sidebar-hover-trigger{display:none}.theme-container.have-rightmenu .page{padding-right:250px}.theme-container.no-sidebar .page{padding-left:0!important}.theme-container.no-sidebar .sidebar-hover-trigger{display:none}.theme-container.hide-navbar .sidebar-hover-trigger{top:4.5rem}.theme-container.hide-navbar .sidebar{top:0}.theme-container.no-sidebar .sidebar-button{display:none}}@media print{.buttons,.navbar,.sidebar{display:none}.page{padding-top:0!important}}@media (min-width:720px) and (max-width:959px){.theme-container.sidebar-open:not(.on-sidebar) .sidebar-button{left:12.6rem}}.home-wrapper .banner .banner-conent .hero h1{font-size:2.8rem!important}table{width:auto}.card-box,.page>:not(.footer){box-shadow:none!important}@media (min-width:940px){.page{padding-top:3.6rem!important}}.home-wrapper .banner .banner-conent{padding:0 2.9rem;box-sizing:border-box}.home-wrapper .banner .slide-banner .slide-banner-wrapper .slide-item a h2{margin-top:2rem;font-size:1.2rem!important}.home-wrapper .banner .slide-banner .slide-banner-wrapper .slide-item a p{padding:0 1rem}.gt-container .gt-ico-tip:after{content:"。( Win + . ) or ( ⌃ + ⌘ + ␣ ) open Emoji";color:#999}.gt-container .gt-meta{border-color:var(--borderColor)!important}.gt-container .gt-comments-null{color:var(--textColor);opacity:.5}.gt-container .gt-header-textarea{color:var(--textColor);background:hsla(0,0%,70.6%,.1)!important}.gt-container .gt-btn{border-color:#11a8cd!important;background-color:#11a8cd!important}.gt-container .gt-btn-preview{background-color:hsla(0,0%,100%,0)!important;color:#11a8cd!important}.gt-container a{color:#11a8cd!important}.gt-container .gt-svg svg{fill:#11a8cd!important}.gt-container .gt-comment-admin .gt-comment-content,.gt-container .gt-comment-content{background-color:hsla(0,0%,58.8%,.1)!important}.gt-container .gt-comment-admin .gt-comment-content:hover,.gt-container .gt-comment-content:hover{box-shadow:0 0 25px hsla(0,0%,58.8%,.5)!important}.gt-container .gt-comment-admin .gt-comment-content .gt-comment-body,.gt-container .gt-comment-content .gt-comment-body{color:var(--textColor)!important}.qq{position:relative}.qq:after{content:"可撩";background:#11a8cd;color:#fff;padding:0 5px;border-radius:10px;font-size:12px;position:absolute;top:-4px;right:-35px;transform:scale(.85)}body .vuepress-plugin-demo-block__wrapper,body .vuepress-plugin-demo-block__wrapper .vuepress-plugin-demo-block__display{border-color:hsla(0,0%,62.7%,.3)}body .vuepress-plugin-demo-block__wrapper .vuepress-plugin-demo-block__footer:hover .vuepress-plugin-demo-block__expand:before{border-top-color:#11a8cd!important;border-bottom-color:#11a8cd!important}body .vuepress-plugin-demo-block__wrapper .vuepress-plugin-demo-block__footer:hover svg{fill:#11a8cd!important}.suggestions{overflow:auto;max-height:calc(100vh - 6rem)}@media (max-width:719px){.suggestions{width:90vw;min-width:90vw!important;margin-right:-20px}}.suggestions .highlight{color:#11a8cd;font-weight:700}#nprogress{pointer-events:none}#nprogress .bar{background:#11a8cd;position:fixed;z-index:1031;top:0;left:0;width:100%;height:2px}#nprogress .peg{display:block;position:absolute;right:0;width:100px;height:100%;box-shadow:0 0 10px #11a8cd,0 0 5px #11a8cd;opacity:1;transform:rotate(3deg) translateY(-4px)}#nprogress .spinner{display:block;position:fixed;z-index:1031;top:15px;right:15px}#nprogress .spinner-icon{width:18px;height:18px;box-sizing:border-box;border-color:#11a8cd transparent transparent #11a8cd;border-style:solid;border-width:2px;border-radius:50%;animation:nprogress-spinner .4s linear infinite}.nprogress-custom-parent{overflow:hidden;position:relative}.nprogress-custom-parent #nprogress .bar,.nprogress-custom-parent #nprogress .spinner{position:absolute}@keyframes nprogress-spinner{0%{transform:rotate(0deg)}to{transform:rotate(1turn)}}.icon.outbound{color:#aaa;display:inline-block;vertical-align:middle;position:relative;top:-1px}.sr-only{position:absolute;width:1px;height:1px;padding:0;margin:-1px;overflow:hidden;clip:rect(0,0,0,0);white-space:nowrap;border-width:0}.theme-mode-light[data-v-439bb2a8]{--bodyBg:#f4f4f4;--customBlockBg:#f1f1f1;--textColor:#00323c;--borderColor:rgba(0,0,0,0.12)}.theme-mode-dark[data-v-439bb2a8]{--bodyBg:#27272b;--customBlockBg:#27272b;--textColor:#9b9baa;--borderColor:#30363d}.theme-mode-read[data-v-439bb2a8]{--bodyBg:#ececcc;--customBlockBg:#ececcc;--textColor:#704214;--textLightenColor:#963}.theme-style-line.theme-mode-light[data-v-439bb2a8]{--bodyBg:#fff}.theme-style-line.theme-mode-dark[data-v-439bb2a8]{--bodyBg:#1e1e22}.theme-style-line.theme-mode-read[data-v-439bb2a8]{--bodyBg:#f5f5d5}.theme-mode-light[data-v-439bb2a8]{--bodyBg:#fff;--mainBg:#fff;--sidebarBg:hsla(0,0%,100%,0.8);--blurBg:hsla(0,0%,100%,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#f6f6f6;--codeColor:#525252}.theme-mode-light code[class*=language-][data-v-439bb2a8],.theme-mode-light pre[class*=language-][data-v-439bb2a8]{color:#000;background:none;text-shadow:0 1px #fff;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-light code[class*=language-][data-v-439bb2a8]::-moz-selection,.theme-mode-light code[class*=language-][data-v-439bb2a8] ::-moz-selection,.theme-mode-light pre[class*=language-][data-v-439bb2a8]::-moz-selection,.theme-mode-light pre[class*=language-][data-v-439bb2a8] ::-moz-selection{text-shadow:none;background:#b3d4fc}.theme-mode-light code[class*=language-][data-v-439bb2a8]::selection,.theme-mode-light code[class*=language-][data-v-439bb2a8] ::selection,.theme-mode-light pre[class*=language-][data-v-439bb2a8]::selection,.theme-mode-light pre[class*=language-][data-v-439bb2a8] ::selection{text-shadow:none;background:#b3d4fc}@media print{.theme-mode-light code[class*=language-][data-v-439bb2a8],.theme-mode-light pre[class*=language-][data-v-439bb2a8]{text-shadow:none}}.theme-mode-light pre[class*=language-][data-v-439bb2a8]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-light :not(pre)>code[class*=language-][data-v-439bb2a8],.theme-mode-light pre[class*=language-][data-v-439bb2a8]{background:#f5f2f0}.theme-mode-light :not(pre)>code[class*=language-][data-v-439bb2a8]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-light .token.cdata[data-v-439bb2a8],.theme-mode-light .token.comment[data-v-439bb2a8],.theme-mode-light .token.doctype[data-v-439bb2a8],.theme-mode-light .token.prolog[data-v-439bb2a8]{color:#708090}.theme-mode-light .token.punctuation[data-v-439bb2a8]{color:#999}.theme-mode-light .namespace[data-v-439bb2a8]{opacity:.7}.theme-mode-light .token.boolean[data-v-439bb2a8],.theme-mode-light .token.constant[data-v-439bb2a8],.theme-mode-light .token.deleted[data-v-439bb2a8],.theme-mode-light .token.number[data-v-439bb2a8],.theme-mode-light .token.property[data-v-439bb2a8],.theme-mode-light .token.symbol[data-v-439bb2a8],.theme-mode-light .token.tag[data-v-439bb2a8]{color:#905}.theme-mode-light .token.attr-name[data-v-439bb2a8],.theme-mode-light .token.builtin[data-v-439bb2a8],.theme-mode-light .token.char[data-v-439bb2a8],.theme-mode-light .token.inserted[data-v-439bb2a8],.theme-mode-light .token.selector[data-v-439bb2a8],.theme-mode-light .token.string[data-v-439bb2a8]{color:#690}.theme-mode-light .language-css .token.string[data-v-439bb2a8],.theme-mode-light .style .token.string[data-v-439bb2a8],.theme-mode-light .token.entity[data-v-439bb2a8],.theme-mode-light .token.operator[data-v-439bb2a8],.theme-mode-light .token.url[data-v-439bb2a8]{color:#9a6e3a;background:hsla(0,0%,100%,.5)}.theme-mode-light .token.atrule[data-v-439bb2a8],.theme-mode-light .token.attr-value[data-v-439bb2a8],.theme-mode-light .token.keyword[data-v-439bb2a8]{color:#07a}.theme-mode-light .token.class-name[data-v-439bb2a8],.theme-mode-light .token.function[data-v-439bb2a8]{color:#dd4a68}.theme-mode-light .token.important[data-v-439bb2a8],.theme-mode-light .token.regex[data-v-439bb2a8],.theme-mode-light .token.variable[data-v-439bb2a8]{color:#e90}.theme-mode-light .token.bold[data-v-439bb2a8],.theme-mode-light .token.important[data-v-439bb2a8]{font-weight:700}.theme-mode-light .token.italic[data-v-439bb2a8]{font-style:italic}.theme-mode-light .token.entity[data-v-439bb2a8]{cursor:help}.theme-mode-light div[class*=language-] .highlight-lines .highlighted[data-v-439bb2a8],.theme-mode-light div[class*=language-].line-numbers-mode .highlight-lines .highlighted[data-v-439bb2a8]:before{background-color:hsla(0,0%,78.4%,.4)}.theme-mode-dark[data-v-439bb2a8]{--bodyBg:#1e1e22;--mainBg:#1e1e22;--sidebarBg:rgba(30,30,34,0.8);--blurBg:rgba(30,30,34,0.8);--textColor:#8c8c96;--textLightenColor:#0085ad;--borderColor:#2c2c3a;--codeBg:#252526;--codeColor:#fff}.theme-mode-dark code[class*=language-][data-v-439bb2a8],.theme-mode-dark pre[class*=language-][data-v-439bb2a8]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-dark pre[class*=language-][data-v-439bb2a8]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-dark :not(pre)>code[class*=language-][data-v-439bb2a8],.theme-mode-dark pre[class*=language-][data-v-439bb2a8]{background:#2d2d2d}.theme-mode-dark :not(pre)>code[class*=language-][data-v-439bb2a8]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-dark .token.block-comment[data-v-439bb2a8],.theme-mode-dark .token.cdata[data-v-439bb2a8],.theme-mode-dark .token.comment[data-v-439bb2a8],.theme-mode-dark .token.doctype[data-v-439bb2a8],.theme-mode-dark .token.prolog[data-v-439bb2a8]{color:#999}.theme-mode-dark .token.punctuation[data-v-439bb2a8]{color:#ccc}.theme-mode-dark .token.attr-name[data-v-439bb2a8],.theme-mode-dark .token.deleted[data-v-439bb2a8],.theme-mode-dark .token.namespace[data-v-439bb2a8],.theme-mode-dark .token.tag[data-v-439bb2a8]{color:#e2777a}.theme-mode-dark .token.function-name[data-v-439bb2a8]{color:#6196cc}.theme-mode-dark .token.boolean[data-v-439bb2a8],.theme-mode-dark .token.function[data-v-439bb2a8],.theme-mode-dark .token.number[data-v-439bb2a8]{color:#f08d49}.theme-mode-dark .token.class-name[data-v-439bb2a8],.theme-mode-dark .token.constant[data-v-439bb2a8],.theme-mode-dark .token.property[data-v-439bb2a8],.theme-mode-dark .token.symbol[data-v-439bb2a8]{color:#f8c555}.theme-mode-dark .token.atrule[data-v-439bb2a8],.theme-mode-dark .token.builtin[data-v-439bb2a8],.theme-mode-dark .token.important[data-v-439bb2a8],.theme-mode-dark .token.keyword[data-v-439bb2a8],.theme-mode-dark .token.selector[data-v-439bb2a8]{color:#cc99cd}.theme-mode-dark .token.attr-value[data-v-439bb2a8],.theme-mode-dark .token.char[data-v-439bb2a8],.theme-mode-dark .token.regex[data-v-439bb2a8],.theme-mode-dark .token.string[data-v-439bb2a8],.theme-mode-dark .token.variable[data-v-439bb2a8]{color:#7ec699}.theme-mode-dark .token.entity[data-v-439bb2a8],.theme-mode-dark .token.operator[data-v-439bb2a8],.theme-mode-dark .token.url[data-v-439bb2a8]{color:#67cdcc}.theme-mode-dark .language-css .token.string[data-v-439bb2a8],.theme-mode-dark .style .token.string[data-v-439bb2a8],.theme-mode-dark .token.entity[data-v-439bb2a8],.theme-mode-dark .token.operator[data-v-439bb2a8],.theme-mode-dark .token.url[data-v-439bb2a8]{background:none}.theme-mode-dark .token.bold[data-v-439bb2a8],.theme-mode-dark .token.important[data-v-439bb2a8]{font-weight:700}.theme-mode-dark .token.italic[data-v-439bb2a8]{font-style:italic}.theme-mode-dark .token.entity[data-v-439bb2a8]{cursor:help}.theme-mode-dark .token.inserted[data-v-439bb2a8]{color:green}.theme-mode-read[data-v-439bb2a8]{--bodyBg:#f5f5d5;--mainBg:#f5f5d5;--sidebarBg:rgba(245,245,213,0.8);--blurBg:rgba(245,245,213,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#282c34;--codeColor:#fff}.theme-mode-read code[class*=language-][data-v-439bb2a8],.theme-mode-read pre[class*=language-][data-v-439bb2a8]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-read pre[class*=language-][data-v-439bb2a8]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-read :not(pre)>code[class*=language-][data-v-439bb2a8],.theme-mode-read pre[class*=language-][data-v-439bb2a8]{background:#2d2d2d}.theme-mode-read :not(pre)>code[class*=language-][data-v-439bb2a8]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-read .token.block-comment[data-v-439bb2a8],.theme-mode-read .token.cdata[data-v-439bb2a8],.theme-mode-read .token.comment[data-v-439bb2a8],.theme-mode-read .token.doctype[data-v-439bb2a8],.theme-mode-read .token.prolog[data-v-439bb2a8]{color:#999}.theme-mode-read .token.punctuation[data-v-439bb2a8]{color:#ccc}.theme-mode-read .token.attr-name[data-v-439bb2a8],.theme-mode-read .token.deleted[data-v-439bb2a8],.theme-mode-read .token.namespace[data-v-439bb2a8],.theme-mode-read .token.tag[data-v-439bb2a8]{color:#e2777a}.theme-mode-read .token.function-name[data-v-439bb2a8]{color:#6196cc}.theme-mode-read .token.boolean[data-v-439bb2a8],.theme-mode-read .token.function[data-v-439bb2a8],.theme-mode-read .token.number[data-v-439bb2a8]{color:#f08d49}.theme-mode-read .token.class-name[data-v-439bb2a8],.theme-mode-read .token.constant[data-v-439bb2a8],.theme-mode-read .token.property[data-v-439bb2a8],.theme-mode-read .token.symbol[data-v-439bb2a8]{color:#f8c555}.theme-mode-read .token.atrule[data-v-439bb2a8],.theme-mode-read .token.builtin[data-v-439bb2a8],.theme-mode-read .token.important[data-v-439bb2a8],.theme-mode-read .token.keyword[data-v-439bb2a8],.theme-mode-read .token.selector[data-v-439bb2a8]{color:#cc99cd}.theme-mode-read .token.attr-value[data-v-439bb2a8],.theme-mode-read .token.char[data-v-439bb2a8],.theme-mode-read .token.regex[data-v-439bb2a8],.theme-mode-read .token.string[data-v-439bb2a8],.theme-mode-read .token.variable[data-v-439bb2a8]{color:#7ec699}.theme-mode-read .token.entity[data-v-439bb2a8],.theme-mode-read .token.operator[data-v-439bb2a8],.theme-mode-read .token.url[data-v-439bb2a8]{color:#67cdcc}.theme-mode-read .language-css .token.string[data-v-439bb2a8],.theme-mode-read .style .token.string[data-v-439bb2a8],.theme-mode-read .token.entity[data-v-439bb2a8],.theme-mode-read .token.operator[data-v-439bb2a8],.theme-mode-read .token.url[data-v-439bb2a8]{background:none}.theme-mode-read .token.bold[data-v-439bb2a8],.theme-mode-read .token.important[data-v-439bb2a8]{font-weight:700}.theme-mode-read .token.italic[data-v-439bb2a8]{font-style:italic}.theme-mode-read .token.entity[data-v-439bb2a8]{cursor:help}.theme-mode-read .token.inserted[data-v-439bb2a8]{color:green}.theme-vdoing-content[data-v-439bb2a8]{margin:3rem auto;padding:1.5rem}.theme-vdoing-content span[data-v-439bb2a8]{font-size:6rem;color:#11a8cd}.main-wrapper{margin:1.5rem auto 0;max-width:1100px;padding:0 .9rem;box-sizing:border-box;position:relative;display:flex}.main-wrapper .main-left{flex:1}.main-wrapper .main-left .theme-vdoing-content.card-box{padding:1rem 1.5rem;margin-bottom:.9rem}.main-wrapper .main-left .home-content{padding:1rem 1.5rem 0}.main-wrapper .main-right>*{width:245px;box-sizing:border-box}@media (max-width:900px){.main-wrapper .main-right>*{width:235px}}.main-wrapper .main-right .card-box{margin:0 0 .8rem .8rem;padding-top:.95rem;padding-bottom:.95rem}@media (max-width:719px){.main-wrapper{margin:.9rem 0;padding:0;display:block}.main-wrapper .main-left{width:100%}.main-wrapper .main-left .post-list{margin-bottom:3rem}.main-wrapper .main-left .post-list .post{border-radius:0}.main-wrapper .main-left .pagination{margin-bottom:3rem}.main-wrapper .main-right .blogger-wrapper{display:none}.main-wrapper .main-right .card-box{margin:0 0 .9rem;border-radius:0;width:100%}.theme-style-line .main-wrapper .main-right .card-box{margin:-1px 0 0}}.post-list{margin-bottom:3rem}.post-list .post{position:relative;padding:1rem 1.5rem;margin-bottom:.8rem;transition:all .3s}.post-list .post:last-child{border-bottom:none}.post-list .post.post-leave-active{display:none}.post-list .post.post-enter{opacity:0;transform:translateX(-20px)}.post-list .post:before{position:absolute;top:-1px;right:0;font-size:2.5rem;color:#ff5722;opacity:.85}.post-list .post .title-wrapper a{color:var(--textColor)}.post-list .post .title-wrapper a:hover{color:#11a8cd}.post-list .post .title-wrapper h2{margin:.5rem 0;font-size:1.4rem;border:none}.post-list .post .title-wrapper h2 .title-tag{height:1.2rem;line-height:1.2rem;border:1px solid #ff5722;color:#ff5722;font-size:.8rem;padding:0 .35rem;border-radius:.2rem;margin-left:0;transform:translateY(-.15rem);display:inline-block}.post-list .post .title-wrapper h2 a{display:block}@media (max-width:719px){.post-list .post .title-wrapper h2 a{font-weight:400}}.post-list .post .title-wrapper .article-info>a,.post-list .post .title-wrapper .article-info>span{opacity:.7;font-size:.8rem;margin-right:1rem;cursor:pointer}.post-list .post .title-wrapper .article-info>a:before,.post-list .post .title-wrapper .article-info>span:before{margin-right:.3rem}.post-list .post .title-wrapper .article-info>a a,.post-list .post .title-wrapper .article-info>span a{margin:0}.post-list .post .title-wrapper .article-info>a a:not(:first-child):before,.post-list .post .title-wrapper .article-info>span a:not(:first-child):before{content:"/"}.post-list .post .title-wrapper .article-info .tags a:not(:first-child):before{content:"、"}.post-list .post .excerpt-wrapper{border-top:1px solid var(--borderColor);margin:.5rem 0;overflow:hidden}.post-list .post .excerpt-wrapper .excerpt{margin-bottom:.3rem;font-size:.92rem}.post-list .post .excerpt-wrapper .excerpt h1,.post-list .post .excerpt-wrapper .excerpt h2,.post-list .post .excerpt-wrapper .excerpt h3{display:none}.post-list .post .excerpt-wrapper .excerpt img{max-height:280px;max-width:100%!important;margin:0 auto}.post-list .post .excerpt-wrapper .readmore{float:right;margin-right:1rem;line-height:1rem}.post-list .post .excerpt-wrapper .readmore:before{float:right;font-size:.8rem;margin:.1rem 0 0 .2rem}.theme-style-line .post-list{border:1px solid var(--borderColor);border-bottom:none;border-radius:5px;overflow:hidden}.theme-style-line .post-list .post{margin-bottom:0;border:none;border-bottom:1px solid var(--borderColor);border-radius:0}.article-list{padding:1rem 2rem}@media (max-width:959px){.article-list{padding:1rem 1.5rem}}.article-list.no-article-list{display:none}.article-list .article-title{border-bottom:1px solid var(--borderColor);font-size:1.3rem;padding:1rem}.article-list .article-title a{font-size:1.2rem;color:var(--textColor);opacity:.9}.article-list .article-title a:before{margin-right:.4rem;font-size:1.1rem}.article-list .article-wrapper{overflow:hidden}.article-list .article-wrapper dl{border-bottom:1px dotted var(--borderColor);float:left;display:flex;padding:8px 0;margin:0;height:45px;width:100%}.article-list .article-wrapper dl dd{font-size:1.1rem;color:#f17229;width:50px;text-align:center;margin:0;line-height:45px}.article-list .article-wrapper dl dt{flex:1;display:flex}.article-list .article-wrapper dl dt a{color:var(--textColor);flex:1;display:flex;height:45px;align-items:center;font-weight:400}.article-list .article-wrapper dl dt a div{overflow:hidden;white-space:normal;text-overflow:ellipsis;display:-webkit-box;-webkit-line-clamp:2;-webkit-box-orient:vertical}.article-list .article-wrapper dl dt a div .title-tag{border:1px solid #ff5722;color:#ff5722;font-size:.8rem;padding:0 .35rem;border-radius:.2rem;margin-left:0;transform:translateY(-.05rem);display:inline-block}.article-list .article-wrapper dl dt a:hover{text-decoration:underline}.article-list .article-wrapper dl dt a.more{color:#11a8cd}.article-list .article-wrapper dl dt .date{width:50px;margin-right:15px;color:#999;text-align:right;font-size:.9rem;line-height:45px}.pagination{position:relative;height:60px;text-align:center}@media (max-width:720px){.pagination{margin-left:1px;margin-right:1px}}.pagination span{line-height:1rem;opacity:.9;cursor:pointer}.pagination span:hover{color:#11a8cd}.pagination span.ellipsis{opacity:.5}.pagination span.ellipsis:before{content:"...";font-size:1.2rem}@media (any-hover:hover){.pagination span.ellipsis.ell-two:hover:before{content:"«"}.pagination span.ellipsis.ell-four:hover:before{content:"»"}}.pagination>span{position:absolute;top:0;padding:1rem 1.2rem;font-size:.95rem}.pagination>span:before{font-size:.4rem}.pagination>span.disabled{color:hsla(0,0%,49%,.5)}.pagination>span.prev{left:0}.pagination>span.prev:before{margin-right:.3rem}.pagination>span.next{right:0}.pagination>span.next:before{float:right;margin-left:.3rem}.pagination>span p{display:inline;line-height:.95rem}.pagination .pagination-list span{display:inline-block;width:2.5rem;height:2.5rem;line-height:2.5rem;margin:.3rem}.pagination .pagination-list span.active{background:#11a8cd;color:var(--mainBg)}@media (max-width:800px){.pagination>span{padding:1rem 1.5rem}.pagination>span p{display:none}}@media (max-width:719px){.pagination>span{padding:.9rem 1.5rem}.pagination .pagination-list span{width:2.3rem;height:2.3rem;line-height:2.3rem;margin:.25rem}}@media (max-width:390px){.pagination>span{padding:.8rem 1.3rem}.pagination .pagination-list span{width:2rem;height:2rem;line-height:2rem;margin:.3rem .1rem .1rem}}.blogger-wrapper{height:auto;display:inline-table;padding-top:0!important;overflow:hidden}.blogger-wrapper .avatar{width:100%;overflow:hidden}.blogger-wrapper .avatar img{width:100%;height:100%}.blogger-wrapper .icons{border-top:none;height:35px;line-height:35px}.blogger-wrapper .icons a{font-size:20px;width:33%;color:var(--textColor);display:block;float:left;text-align:center;opacity:.8}.blogger-wrapper .icons a:hover{color:#11a8cd}.blogger-wrapper .blogger{padding:.3rem .95rem 0}.blogger-wrapper .blogger .name{font-size:1.3rem;display:block;margin-bottom:6px}.blogger-wrapper .blogger .slogan{color:var(--textColor)}.categories-wrapper .title{color:var(--textColor);opacity:.9;font-size:1.2rem;padding:0 .95rem}.categories-wrapper .title:before{margin-right:.3rem}.categories-wrapper .categories{margin-top:.6rem}.categories-wrapper .categories a{display:block;padding:8px .95rem 7px;color:var(--textColor);opacity:.8;font-size:.95rem;line-height:.95rem;position:relative;transition:all .2s;border-left:2px solid transparent;margin-top:-1px;overflow:hidden;white-space:nowrap;text-overflow:ellipsis}@media (max-width:719px){.categories-wrapper .categories a{font-weight:400}}.categories-wrapper .categories a:not(.active):hover{color:#11a8cd;background:#f8f8f8;border-color:#11a8cd}.categories-wrapper .categories a:not(.active):hover span{opacity:.8}.categories-wrapper .categories a span{float:right;background-color:var(--textColor);color:var(--mainBg);border-radius:8px;padding:0 .13rem;min-width:1rem;height:1rem;line-height:1rem;font-size:.6rem;text-align:center;opacity:.6;transition:opacity .3s}.categories-wrapper .categories a.active{background:#11a8cd;color:var(--mainBg);padding-left:.8rem;border-radius:1px;border-color:transparent}.theme-mode-dark .categories-wrapper .categories a:not(.active):hover,.theme-mode-read .categories-wrapper .categories a:not(.active):hover{background:var(--customBlockBg)}.tags-wrapper{padding:0 .95rem}.tags-wrapper .title{color:var(--textColor);opacity:.9;font-size:1.2rem}.tags-wrapper .title:before{margin-right:.3rem}.tags-wrapper .tags{text-align:justify;padding:.8rem .5rem .5rem;margin:0 -.5rem -.5rem}.tags-wrapper .tags a{opacity:.8;display:inline-block;padding:.2rem .4rem;transition:all .4s;background-color:var(--textColor);color:var(--mainBg);border-radius:3px;margin:0 .3rem .5rem 0;min-width:2rem;height:1rem;line-height:1rem;font-size:.8rem;text-align:center}@media (max-width:719px){.tags-wrapper .tags a{font-weight:400}}.tags-wrapper .tags a:hover{opacity:1;transform:scale(1.1)}.tags-wrapper .tags a.active{box-shadow:0 5px 10px -5px var(--randomColor,rgba(0,0,0,.15));transform:scale(1.22);opacity:1}.tags-wrapper .tags a.active:hover{text-decoration:none}.theme-mode-light[data-v-7d2bb426]{--bodyBg:#f4f4f4;--customBlockBg:#f1f1f1;--textColor:#00323c;--borderColor:rgba(0,0,0,0.12)}.theme-mode-dark[data-v-7d2bb426]{--bodyBg:#27272b;--customBlockBg:#27272b;--textColor:#9b9baa;--borderColor:#30363d}.theme-mode-read[data-v-7d2bb426]{--bodyBg:#ececcc;--customBlockBg:#ececcc;--textColor:#704214;--textLightenColor:#963}.theme-style-line.theme-mode-light[data-v-7d2bb426]{--bodyBg:#fff}.theme-style-line.theme-mode-dark[data-v-7d2bb426]{--bodyBg:#1e1e22}.theme-style-line.theme-mode-read[data-v-7d2bb426]{--bodyBg:#f5f5d5}.theme-mode-light[data-v-7d2bb426]{--bodyBg:#fff;--mainBg:#fff;--sidebarBg:hsla(0,0%,100%,0.8);--blurBg:hsla(0,0%,100%,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#f6f6f6;--codeColor:#525252}.theme-mode-light code[class*=language-][data-v-7d2bb426],.theme-mode-light pre[class*=language-][data-v-7d2bb426]{color:#000;background:none;text-shadow:0 1px #fff;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-light code[class*=language-][data-v-7d2bb426]::-moz-selection,.theme-mode-light code[class*=language-][data-v-7d2bb426] ::-moz-selection,.theme-mode-light pre[class*=language-][data-v-7d2bb426]::-moz-selection,.theme-mode-light pre[class*=language-][data-v-7d2bb426] ::-moz-selection{text-shadow:none;background:#b3d4fc}.theme-mode-light code[class*=language-][data-v-7d2bb426]::selection,.theme-mode-light code[class*=language-][data-v-7d2bb426] ::selection,.theme-mode-light pre[class*=language-][data-v-7d2bb426]::selection,.theme-mode-light pre[class*=language-][data-v-7d2bb426] ::selection{text-shadow:none;background:#b3d4fc}@media print{.theme-mode-light code[class*=language-][data-v-7d2bb426],.theme-mode-light pre[class*=language-][data-v-7d2bb426]{text-shadow:none}}.theme-mode-light pre[class*=language-][data-v-7d2bb426]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-light :not(pre)>code[class*=language-][data-v-7d2bb426],.theme-mode-light pre[class*=language-][data-v-7d2bb426]{background:#f5f2f0}.theme-mode-light :not(pre)>code[class*=language-][data-v-7d2bb426]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-light .token.cdata[data-v-7d2bb426],.theme-mode-light .token.comment[data-v-7d2bb426],.theme-mode-light .token.doctype[data-v-7d2bb426],.theme-mode-light .token.prolog[data-v-7d2bb426]{color:#708090}.theme-mode-light .token.punctuation[data-v-7d2bb426]{color:#999}.theme-mode-light .namespace[data-v-7d2bb426]{opacity:.7}.theme-mode-light .token.boolean[data-v-7d2bb426],.theme-mode-light .token.constant[data-v-7d2bb426],.theme-mode-light .token.deleted[data-v-7d2bb426],.theme-mode-light .token.number[data-v-7d2bb426],.theme-mode-light .token.property[data-v-7d2bb426],.theme-mode-light .token.symbol[data-v-7d2bb426],.theme-mode-light .token.tag[data-v-7d2bb426]{color:#905}.theme-mode-light .token.attr-name[data-v-7d2bb426],.theme-mode-light .token.builtin[data-v-7d2bb426],.theme-mode-light .token.char[data-v-7d2bb426],.theme-mode-light .token.inserted[data-v-7d2bb426],.theme-mode-light .token.selector[data-v-7d2bb426],.theme-mode-light .token.string[data-v-7d2bb426]{color:#690}.theme-mode-light .language-css .token.string[data-v-7d2bb426],.theme-mode-light .style .token.string[data-v-7d2bb426],.theme-mode-light .token.entity[data-v-7d2bb426],.theme-mode-light .token.operator[data-v-7d2bb426],.theme-mode-light .token.url[data-v-7d2bb426]{color:#9a6e3a;background:hsla(0,0%,100%,.5)}.theme-mode-light .token.atrule[data-v-7d2bb426],.theme-mode-light .token.attr-value[data-v-7d2bb426],.theme-mode-light .token.keyword[data-v-7d2bb426]{color:#07a}.theme-mode-light .token.class-name[data-v-7d2bb426],.theme-mode-light .token.function[data-v-7d2bb426]{color:#dd4a68}.theme-mode-light .token.important[data-v-7d2bb426],.theme-mode-light .token.regex[data-v-7d2bb426],.theme-mode-light .token.variable[data-v-7d2bb426]{color:#e90}.theme-mode-light .token.bold[data-v-7d2bb426],.theme-mode-light .token.important[data-v-7d2bb426]{font-weight:700}.theme-mode-light .token.italic[data-v-7d2bb426]{font-style:italic}.theme-mode-light .token.entity[data-v-7d2bb426]{cursor:help}.theme-mode-light div[class*=language-] .highlight-lines .highlighted[data-v-7d2bb426],.theme-mode-light div[class*=language-].line-numbers-mode .highlight-lines .highlighted[data-v-7d2bb426]:before{background-color:hsla(0,0%,78.4%,.4)}.theme-mode-dark[data-v-7d2bb426]{--bodyBg:#1e1e22;--mainBg:#1e1e22;--sidebarBg:rgba(30,30,34,0.8);--blurBg:rgba(30,30,34,0.8);--textColor:#8c8c96;--textLightenColor:#0085ad;--borderColor:#2c2c3a;--codeBg:#252526;--codeColor:#fff}.theme-mode-dark code[class*=language-][data-v-7d2bb426],.theme-mode-dark pre[class*=language-][data-v-7d2bb426]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-dark pre[class*=language-][data-v-7d2bb426]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-dark :not(pre)>code[class*=language-][data-v-7d2bb426],.theme-mode-dark pre[class*=language-][data-v-7d2bb426]{background:#2d2d2d}.theme-mode-dark :not(pre)>code[class*=language-][data-v-7d2bb426]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-dark .token.block-comment[data-v-7d2bb426],.theme-mode-dark .token.cdata[data-v-7d2bb426],.theme-mode-dark .token.comment[data-v-7d2bb426],.theme-mode-dark .token.doctype[data-v-7d2bb426],.theme-mode-dark .token.prolog[data-v-7d2bb426]{color:#999}.theme-mode-dark .token.punctuation[data-v-7d2bb426]{color:#ccc}.theme-mode-dark .token.attr-name[data-v-7d2bb426],.theme-mode-dark .token.deleted[data-v-7d2bb426],.theme-mode-dark .token.namespace[data-v-7d2bb426],.theme-mode-dark .token.tag[data-v-7d2bb426]{color:#e2777a}.theme-mode-dark .token.function-name[data-v-7d2bb426]{color:#6196cc}.theme-mode-dark .token.boolean[data-v-7d2bb426],.theme-mode-dark .token.function[data-v-7d2bb426],.theme-mode-dark .token.number[data-v-7d2bb426]{color:#f08d49}.theme-mode-dark .token.class-name[data-v-7d2bb426],.theme-mode-dark .token.constant[data-v-7d2bb426],.theme-mode-dark .token.property[data-v-7d2bb426],.theme-mode-dark .token.symbol[data-v-7d2bb426]{color:#f8c555}.theme-mode-dark .token.atrule[data-v-7d2bb426],.theme-mode-dark .token.builtin[data-v-7d2bb426],.theme-mode-dark .token.important[data-v-7d2bb426],.theme-mode-dark .token.keyword[data-v-7d2bb426],.theme-mode-dark .token.selector[data-v-7d2bb426]{color:#cc99cd}.theme-mode-dark .token.attr-value[data-v-7d2bb426],.theme-mode-dark .token.char[data-v-7d2bb426],.theme-mode-dark .token.regex[data-v-7d2bb426],.theme-mode-dark .token.string[data-v-7d2bb426],.theme-mode-dark .token.variable[data-v-7d2bb426]{color:#7ec699}.theme-mode-dark .token.entity[data-v-7d2bb426],.theme-mode-dark .token.operator[data-v-7d2bb426],.theme-mode-dark .token.url[data-v-7d2bb426]{color:#67cdcc}.theme-mode-dark .language-css .token.string[data-v-7d2bb426],.theme-mode-dark .style .token.string[data-v-7d2bb426],.theme-mode-dark .token.entity[data-v-7d2bb426],.theme-mode-dark .token.operator[data-v-7d2bb426],.theme-mode-dark .token.url[data-v-7d2bb426]{background:none}.theme-mode-dark .token.bold[data-v-7d2bb426],.theme-mode-dark .token.important[data-v-7d2bb426]{font-weight:700}.theme-mode-dark .token.italic[data-v-7d2bb426]{font-style:italic}.theme-mode-dark .token.entity[data-v-7d2bb426]{cursor:help}.theme-mode-dark .token.inserted[data-v-7d2bb426]{color:green}.theme-mode-read[data-v-7d2bb426]{--bodyBg:#f5f5d5;--mainBg:#f5f5d5;--sidebarBg:rgba(245,245,213,0.8);--blurBg:rgba(245,245,213,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#282c34;--codeColor:#fff}.theme-mode-read code[class*=language-][data-v-7d2bb426],.theme-mode-read pre[class*=language-][data-v-7d2bb426]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-read pre[class*=language-][data-v-7d2bb426]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-read :not(pre)>code[class*=language-][data-v-7d2bb426],.theme-mode-read pre[class*=language-][data-v-7d2bb426]{background:#2d2d2d}.theme-mode-read :not(pre)>code[class*=language-][data-v-7d2bb426]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-read .token.block-comment[data-v-7d2bb426],.theme-mode-read .token.cdata[data-v-7d2bb426],.theme-mode-read .token.comment[data-v-7d2bb426],.theme-mode-read .token.doctype[data-v-7d2bb426],.theme-mode-read .token.prolog[data-v-7d2bb426]{color:#999}.theme-mode-read .token.punctuation[data-v-7d2bb426]{color:#ccc}.theme-mode-read .token.attr-name[data-v-7d2bb426],.theme-mode-read .token.deleted[data-v-7d2bb426],.theme-mode-read .token.namespace[data-v-7d2bb426],.theme-mode-read .token.tag[data-v-7d2bb426]{color:#e2777a}.theme-mode-read .token.function-name[data-v-7d2bb426]{color:#6196cc}.theme-mode-read .token.boolean[data-v-7d2bb426],.theme-mode-read .token.function[data-v-7d2bb426],.theme-mode-read .token.number[data-v-7d2bb426]{color:#f08d49}.theme-mode-read .token.class-name[data-v-7d2bb426],.theme-mode-read .token.constant[data-v-7d2bb426],.theme-mode-read .token.property[data-v-7d2bb426],.theme-mode-read .token.symbol[data-v-7d2bb426]{color:#f8c555}.theme-mode-read .token.atrule[data-v-7d2bb426],.theme-mode-read .token.builtin[data-v-7d2bb426],.theme-mode-read .token.important[data-v-7d2bb426],.theme-mode-read .token.keyword[data-v-7d2bb426],.theme-mode-read .token.selector[data-v-7d2bb426]{color:#cc99cd}.theme-mode-read .token.attr-value[data-v-7d2bb426],.theme-mode-read .token.char[data-v-7d2bb426],.theme-mode-read .token.regex[data-v-7d2bb426],.theme-mode-read .token.string[data-v-7d2bb426],.theme-mode-read .token.variable[data-v-7d2bb426]{color:#7ec699}.theme-mode-read .token.entity[data-v-7d2bb426],.theme-mode-read .token.operator[data-v-7d2bb426],.theme-mode-read .token.url[data-v-7d2bb426]{color:#67cdcc}.theme-mode-read .language-css .token.string[data-v-7d2bb426],.theme-mode-read .style .token.string[data-v-7d2bb426],.theme-mode-read .token.entity[data-v-7d2bb426],.theme-mode-read .token.operator[data-v-7d2bb426],.theme-mode-read .token.url[data-v-7d2bb426]{background:none}.theme-mode-read .token.bold[data-v-7d2bb426],.theme-mode-read .token.important[data-v-7d2bb426]{font-weight:700}.theme-mode-read .token.italic[data-v-7d2bb426]{font-style:italic}.theme-mode-read .token.entity[data-v-7d2bb426]{cursor:help}.theme-mode-read .token.inserted[data-v-7d2bb426]{color:green}.home-wrapper .banner[data-v-7d2bb426]{width:100%;min-height:450px;margin-top:3.6rem;color:#fff;position:relative;overflow:hidden}.home-wrapper .banner .banner-conent[data-v-7d2bb426]{max-width:1100px;margin:0 auto;position:relative;z-index:1;overflow:hidden}.home-wrapper .banner .banner-conent .hero[data-v-7d2bb426]{text-align:center;margin-top:3rem}.home-wrapper .banner .banner-conent .hero img[data-v-7d2bb426]{max-width:100%;max-height:240px;display:block;margin:2rem auto 1.5rem}.home-wrapper .banner .banner-conent .hero h1[data-v-7d2bb426]{margin:0;font-size:3.2rem}.home-wrapper .banner .banner-conent .hero .action[data-v-7d2bb426],.home-wrapper .banner .banner-conent .hero .description[data-v-7d2bb426]{margin:1.5rem auto}.home-wrapper .banner .banner-conent .hero .description[data-v-7d2bb426]{max-width:40rem;font-size:1.1rem;line-height:1.3;opacity:.9}.home-wrapper .banner .banner-conent .hero .action-button[data-v-7d2bb426]{display:inline-block;font-size:1.2rem;background-color:#11a8cd;padding:.8rem 1.6rem;border-radius:4px;transition:background-color .1s ease;box-sizing:border-box;border-bottom:1px solid #0f97b9;color:#fff}.home-wrapper .banner .banner-conent .hero .action-button[data-v-7d2bb426]:hover{background-color:#13bee8}.home-wrapper .banner .banner-conent .features[data-v-7d2bb426]{padding:2rem 0;margin-top:2.5rem;display:flex;flex-wrap:wrap;align-items:flex-start;align-content:stretch;justify-content:space-between}.home-wrapper .banner .banner-conent .feature[data-v-7d2bb426]{flex-grow:1;flex-basis:30%;max-width:30%;text-align:center}.home-wrapper .banner .banner-conent .feature a[data-v-7d2bb426]{color:inherit}.home-wrapper .banner .banner-conent .feature a .feature-img[data-v-7d2bb426]{width:10rem;height:10rem;animation:heart-7d2bb426 1.2s ease-in-out 0s infinite alternate;animation-play-state:paused}.home-wrapper .banner .banner-conent .feature a h2[data-v-7d2bb426]{font-weight:500;font-size:1.3rem;border-bottom:none;padding-bottom:0}.home-wrapper .banner .banner-conent .feature a p[data-v-7d2bb426]{opacity:.8;padding:0 .8rem}.home-wrapper .banner .banner-conent .feature:hover .feature-img[data-v-7d2bb426]{animation-play-state:running}.home-wrapper .banner .banner-conent .feature:hover h2[data-v-7d2bb426],.home-wrapper .banner .banner-conent .feature:hover p[data-v-7d2bb426]{color:#11a8cd}.home-wrapper .banner .slide-banner[data-v-7d2bb426]{margin-top:2rem}.home-wrapper .banner .slide-banner .banner-wrapper[data-v-7d2bb426]{position:relative}.home-wrapper .banner .slide-banner .slide-banner-scroll[data-v-7d2bb426]{min-height:1px;overflow:hidden}.home-wrapper .banner .slide-banner .slide-banner-wrapper[data-v-7d2bb426]{height:300px}.home-wrapper .banner .slide-banner .slide-banner-wrapper .slide-item[data-v-7d2bb426]{display:inline-block;height:300px;width:100%;text-align:center}.home-wrapper .banner .slide-banner .slide-banner-wrapper .slide-item a[data-v-7d2bb426]{color:inherit}.home-wrapper .banner .slide-banner .slide-banner-wrapper .slide-item a .feature-img[data-v-7d2bb426]{width:10rem;height:10rem}.home-wrapper .banner .slide-banner .slide-banner-wrapper .slide-item a h2[data-v-7d2bb426]{font-size:1.1rem;font-weight:500;border-bottom:none;padding-bottom:0}.home-wrapper .banner .slide-banner .slide-banner-wrapper .slide-item a p[data-v-7d2bb426]{opacity:.8;padding:0 .8rem}.home-wrapper .banner .slide-banner .docs-wrapper[data-v-7d2bb426]{position:absolute;bottom:25px;left:50%;transform:translateX(-50%)}.home-wrapper .banner .slide-banner .docs-wrapper .doc[data-v-7d2bb426]{display:inline-block;margin:0 4px;width:8px;height:8px;border-radius:50%;background:var(--textColor);opacity:.9}.home-wrapper .banner .slide-banner .docs-wrapper .doc.active[data-v-7d2bb426]{opacity:.5}.home-wrapper .banner.hide-banner[data-v-7d2bb426]{display:none}.home-wrapper .banner.hide-banner+.main-wrapper[data-v-7d2bb426]{margin-top:4.5rem}.home-wrapper .main-wrapper[data-v-7d2bb426]{margin-top:2rem}.home-wrapper .main-wrapper .main-left .card-box[data-v-7d2bb426]{margin-bottom:2rem}.home-wrapper .main-wrapper .main-left .pagination[data-v-7d2bb426]{margin-bottom:3rem}.home-wrapper .main-wrapper .main-left .theme-vdoing-content[data-v-7d2bb426]{padding:0 2rem;overflow:hidden;border:none}.home-wrapper .main-wrapper .main-left .theme-vdoing-content[data-v-7d2bb426]>:first-child{padding-top:2rem}.home-wrapper .main-wrapper .main-left .theme-vdoing-content[data-v-7d2bb426]>:last-child{padding-bottom:2rem}.home-wrapper .main-wrapper .main-right .custom-html-box[data-v-7d2bb426]{padding:0;overflow:hidden}@media (max-width:1025px){.home-wrapper .banner .banner-conent .hero h1[data-v-7d2bb426]{font-size:2.5rem}.home-wrapper .banner .banner-conent .hero .description[data-v-7d2bb426]{font-size:1rem}.home-wrapper .banner .banner-conent .feature a h2[data-v-7d2bb426]{font-size:1.1rem}.home-wrapper .banner .banner-conent .feature a .feature-img[data-v-7d2bb426]{width:9rem;height:9rem}}@media (max-width:719px){.home-wrapper .banner .banner-conent .features[data-v-7d2bb426]{display:none!important}}@media (max-width:419px){.home-wrapper .banner-conent[data-v-7d2bb426]{padding-left:1.5rem;padding-right:1.5rem}.home-wrapper .banner-conent .hero img[data-v-7d2bb426]{max-height:210px;margin:2rem auto 1.2rem}.home-wrapper .banner-conent .hero h1[data-v-7d2bb426]{font-size:2rem}.home-wrapper .banner-conent .hero .action[data-v-7d2bb426],.home-wrapper .banner-conent .hero .description[data-v-7d2bb426],.home-wrapper .banner-conent .hero h1[data-v-7d2bb426]{margin:1.2rem auto}.home-wrapper .banner-conent .hero .description[data-v-7d2bb426]{font-size:1.2rem}.home-wrapper .banner-conent .hero .action-button[data-v-7d2bb426]{font-size:1rem;padding:.6rem 1.2rem}.home-wrapper .banner-conent .feature h2[data-v-7d2bb426]{font-size:1.25rem}}@media (max-width:719px){.theme-style-line .main-wrapper[data-v-7d2bb426]{margin-top:-1px}}@keyframes heart-7d2bb426{0%{transform:translate(0)}to{transform:translateY(8px)}}.search-box{display:inline-block;position:relative;margin-right:1rem}.search-box input{cursor:text;width:10rem;height:2rem;color:#4e6e8e;display:inline-block;border:1px solid #cfd4db;border-radius:2rem;font-size:.9rem;line-height:2rem;padding:0 .5rem 0 2rem;outline:none;transition:all .2s ease;background:#fff url(/db-tutorial/assets/img/search.237d6f6a.svg) .6rem .5rem no-repeat;background-size:1rem}.search-box input:focus{cursor:auto;border-color:#11a8cd}.search-box .suggestions{background:#fff;min-width:500px;max-width:700px;position:absolute;top:2rem;border:1px solid #cfd4db;border-radius:6px;padding:.4rem;list-style-type:none}.search-box .suggestions.align-right{right:0}.search-box .suggestion{line-height:1.4;border-radius:4px;cursor:pointer;width:100%}.search-box .suggestion a{display:block;white-space:normal;color:#415b75;width:100%}.search-box .suggestion a .parent-page-title{color:#fff;font-weight:600;background-color:#11a8cd;padding:5px}.search-box .suggestion a .suggestion-row{border-collapse:collapse;width:100%;display:table}.search-box .suggestion a .suggestion-row .page-title{width:35%;background:#f5f5f5;border:1px solid #eaecef;border-left:none;display:table-cell;text-align:right;padding:5px;font-weight:600}.search-box .suggestion a .suggestion-row .suggestion-content{font-weight:400;border:1px solid #eaecef;border-right:none;width:65%;display:table-cell;padding:5px}.search-box .suggestion a .suggestion-row .suggestion-content .highlight{text-decoration:underline}.search-box .suggestion a .suggestion-row .suggestion-content .header{font-weight:600}.search-box .suggestion.focused{background-color:#f3f4f5}@media (max-width:959px){.search-box input{cursor:pointer;width:0;border-color:transparent;position:relative}.search-box input:focus{cursor:text;left:0;width:10rem}}@media (-ms-high-contrast:none){.search-box input{height:2rem}}@media (max-width:959px) and (min-width:719px){.search-box .suggestions{left:0}}@media (max-width:719px){.search-box{margin-right:0}.search-box input{left:1rem}.search-box .suggestions{right:0}}@media (max-width:419px){.search-box .suggestions{width:calc(100vw - 4rem)}.search-box input:focus{width:8rem}}.sidebar-button{cursor:pointer;display:none;width:1.25rem;height:1.25rem;position:absolute;padding:.6rem;top:.6rem;left:1rem}@media (max-width:719px){.sidebar-button{display:block}}.sidebar-button .icon{display:block;width:1.25rem;height:1.25rem}@media (min-width:720px){.sidebar-button{width:40px;height:40px;display:inline-block;position:fixed;left:0;top:4.6rem;text-align:center;line-height:44px;margin:5px 8px;color:#888;border-radius:50%;padding:0;transition:all .2s}.sidebar-button:hover{background:#11a8cd;color:#fff;box-shadow:0 0 6px #11a8cd}.sidebar-button .icon{display:inline;width:1rem;height:1rem}}.dropdown-enter,.dropdown-leave-to{height:0!important}.dropdown-wrapper{cursor:pointer}.dropdown-wrapper .dropdown-title{display:block;font-size:.9rem;font-family:inherit;cursor:inherit;padding:inherit;line-height:1.4rem;background:transparent;border:none;font-weight:500;color:var(--textColor)}.dropdown-wrapper .dropdown-title:hover{border-color:transparent}.dropdown-wrapper .dropdown-title .arrow{vertical-align:middle;margin-top:-1px;margin-left:.4rem}.dropdown-wrapper .nav-dropdown .dropdown-item{color:inherit;line-height:1.7rem}.dropdown-wrapper .nav-dropdown .dropdown-item h4{margin:.45rem 0 0;border-top:1px solid var(--borderColor);padding:.45rem 1.5rem 0 1.25rem}.dropdown-wrapper .nav-dropdown .dropdown-item .dropdown-subitem-wrapper{padding:0;list-style:none}.dropdown-wrapper .nav-dropdown .dropdown-item .dropdown-subitem-wrapper .dropdown-subitem{font-size:.9em}.dropdown-wrapper .nav-dropdown .dropdown-item a{display:block;line-height:1.7rem;position:relative;border-bottom:none;font-weight:400;margin-bottom:0;padding:0 1.5rem 0 1.25rem}.dropdown-wrapper .nav-dropdown .dropdown-item a.router-link-active,.dropdown-wrapper .nav-dropdown .dropdown-item a:hover{color:#11a8cd}.dropdown-wrapper .nav-dropdown .dropdown-item a.router-link-active:after{content:"";width:0;height:0;border-left:5px solid #11a8cd;border-top:3px solid transparent;border-bottom:3px solid transparent;position:absolute;top:calc(50% - 2px);left:9px}.dropdown-wrapper .nav-dropdown .dropdown-item:first-child h4{margin-top:0;padding-top:0;border-top:0}@media (max-width:719px){.dropdown-wrapper.open .dropdown-title{margin-bottom:.5rem}.dropdown-wrapper .dropdown-title{font-weight:600;font-size:inherit}.dropdown-wrapper .dropdown-title:hover{color:#11a8cd}.dropdown-wrapper .dropdown-title .link-title{display:none}.dropdown-wrapper .dropdown-title .title{display:inline-block!important}.dropdown-wrapper .nav-dropdown{transition:height .1s ease-out;overflow:hidden}.dropdown-wrapper .nav-dropdown .dropdown-item h4{border-top:0;margin-top:0;padding-top:0}.dropdown-wrapper .nav-dropdown .dropdown-item>a,.dropdown-wrapper .nav-dropdown .dropdown-item h4{font-size:15px;line-height:2rem}.dropdown-wrapper .nav-dropdown .dropdown-item .dropdown-subitem{font-size:14px;padding-left:1rem}}@media (min-width:719px){.dropdown-wrapper{height:1.8rem}.dropdown-wrapper.open .nav-dropdown,.dropdown-wrapper:hover .nav-dropdown{display:block!important}.dropdown-wrapper.open:blur{display:none}.dropdown-wrapper .dropdown-title .arrow{border-left:4px solid transparent;border-right:4px solid transparent;border-top:6px solid #ccc;border-bottom:0}.dropdown-wrapper .nav-dropdown{display:none;height:auto!important;box-sizing:border-box;max-height:calc(100vh - 2.7rem);overflow-y:auto;position:absolute;top:100%;right:0;background-color:var(--mainBg);padding:.6rem 0;border-bottom-color:var(--borderColor);border:1px solid var(--borderColor);text-align:left;border-radius:.25rem;white-space:nowrap;margin:0}.nav-item .dropdown-title a.router-link-active,.nav-item .dropdown-title a:hover{margin-bottom:-2px;border-bottom:2px solid #13b9e2}}.nav-links{display:inline-block}.nav-links a{line-height:1.4rem;color:inherit}.nav-links a.router-link-active,.nav-links a:hover{color:#11a8cd}.nav-links .nav-item{position:relative;display:inline-block;margin-left:1.5rem;line-height:2rem}.nav-links .nav-item:first-child{margin-left:0}.nav-links .repo-link{margin-left:1.5rem}@media (max-width:959px){.nav-links .nav-item{margin-left:1.2rem}}@media (max-width:719px){.nav-links .nav-item,.nav-links .repo-link{margin-left:0}}@media (min-width:719px){.nav-links a.router-link-active,.nav-links a:hover{color:var(--textColor)}.nav-item>a:not(.external).router-link-active,.nav-item>a:not(.external):hover{margin-bottom:-2px;border-bottom:2px solid #13b9e2}}.navbar{padding:.7rem 1.5rem;line-height:2.2rem;transition:transform .3s}.navbar a,.navbar img,.navbar span{display:inline-block}.navbar .logo{height:2.2rem;min-width:2.2rem;margin-right:.8rem;vertical-align:top}.navbar .site-name{font-size:1.3rem;font-weight:600;color:var(--textColor);position:relative}.navbar .links{padding-left:1.5rem;box-sizing:border-box;white-space:nowrap;font-size:.9rem;position:absolute;right:1.5rem;top:.7rem;display:flex}.navbar .links .search-box{flex:0 0 auto;vertical-align:top}.hide-navbar .navbar{transform:translateY(-100%)}@media (max-width:959px){.navbar .site-name{display:none}}@media (max-width:719px){.navbar{padding-left:4rem}.navbar .can-hide{display:none}.navbar .links{padding-left:1.5rem}.navbar .site-name{width:calc(100vw - 9.4rem);overflow:hidden;white-space:nowrap;text-overflow:ellipsis}}.page-edit{max-width:860px;padding-top:1rem;padding-bottom:1rem;overflow:auto}.page-edit .edit-link{display:inline-block;float:left;margin:0 2rem .5rem 0}.page-edit .edit-link a{margin-right:.25rem}.page-edit .tags{float:left}.page-edit .tags a{margin:0 .8rem .5rem 0;display:inline-block;color:var(--textLightenColor);padding:.2rem .7rem;font-size:.9em;background-color:hsla(0,0%,50.2%,.08);border-radius:3px;opacity:.8}.page-edit .last-updated{float:right;font-size:.9em}.page-edit .last-updated .prefix{font-weight:500;color:var(--textColor);opacity:.8}.page-edit .last-updated .time{font-weight:400;color:#aaa}@media (max-width:719px){.page-edit .edit-link,.page-edit .tags{margin-bottom:.5rem}.page-edit .last-updated{width:100%;font-size:.8em;text-align:left}}.page-nav{max-width:860px;padding-top:1rem;padding-bottom:0}.page-nav .inner{min-height:2rem;margin-top:0;border-top:1px solid var(--borderColor);padding-top:1rem;overflow:auto}.page-nav .next{float:right}.page-nav-centre-wrap .page-nav-centre{position:fixed;top:50%;width:80px;height:70px;margin-top:-35px;outline:0;transition:all .2s;border-radius:3px;opacity:.55;z-index:99}@media (max-width:1340px){.page-nav-centre-wrap .page-nav-centre{width:50px}}@media (max-width:960px){.page-nav-centre-wrap .page-nav-centre{display:none}}.page-nav-centre-wrap .page-nav-centre:hover{background:hsla(0,0%,60%,.15);opacity:1}.page-nav-centre-wrap .page-nav-centre:hover .tooltip{display:block}.page-nav-centre-wrap .page-nav-centre:before{content:"";display:block;width:10px;height:10px;border-top:2px solid #999;border-right:2px solid #999;position:absolute;top:0;right:0;bottom:0;left:0;margin:auto}.page-nav-centre-wrap .page-nav-centre .tooltip{display:none;background:rgba(0,0,0,.5);color:#fff;padding:4px 8px;font-size:13px;border-radius:3px;position:fixed;max-width:200px;z-index:99}.page-nav-centre-wrap .page-nav-centre-prev{left:0}.page-nav-centre-wrap .page-nav-centre-prev:before{transform:rotate(-135deg)}.page-nav-centre-wrap .page-nav-centre-next{right:0}.page-nav-centre-wrap .page-nav-centre-next:before{transform:rotate(45deg)}.sidebar-open .page-nav-centre-wrap .page-nav-centre-prev{left:18rem}.no-sidebar .page-nav-centre-wrap .page-nav-centre-prev{left:0}.theme-mode-light[data-v-06225672]{--bodyBg:#f4f4f4;--customBlockBg:#f1f1f1;--textColor:#00323c;--borderColor:rgba(0,0,0,0.12)}.theme-mode-dark[data-v-06225672]{--bodyBg:#27272b;--customBlockBg:#27272b;--textColor:#9b9baa;--borderColor:#30363d}.theme-mode-read[data-v-06225672]{--bodyBg:#ececcc;--customBlockBg:#ececcc;--textColor:#704214;--textLightenColor:#963}.theme-style-line.theme-mode-light[data-v-06225672]{--bodyBg:#fff}.theme-style-line.theme-mode-dark[data-v-06225672]{--bodyBg:#1e1e22}.theme-style-line.theme-mode-read[data-v-06225672]{--bodyBg:#f5f5d5}.theme-mode-light[data-v-06225672]{--bodyBg:#fff;--mainBg:#fff;--sidebarBg:hsla(0,0%,100%,0.8);--blurBg:hsla(0,0%,100%,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#f6f6f6;--codeColor:#525252}.theme-mode-light code[class*=language-][data-v-06225672],.theme-mode-light pre[class*=language-][data-v-06225672]{color:#000;background:none;text-shadow:0 1px #fff;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-light code[class*=language-][data-v-06225672]::-moz-selection,.theme-mode-light code[class*=language-][data-v-06225672] ::-moz-selection,.theme-mode-light pre[class*=language-][data-v-06225672]::-moz-selection,.theme-mode-light pre[class*=language-][data-v-06225672] ::-moz-selection{text-shadow:none;background:#b3d4fc}.theme-mode-light code[class*=language-][data-v-06225672]::selection,.theme-mode-light code[class*=language-][data-v-06225672] ::selection,.theme-mode-light pre[class*=language-][data-v-06225672]::selection,.theme-mode-light pre[class*=language-][data-v-06225672] ::selection{text-shadow:none;background:#b3d4fc}@media print{.theme-mode-light code[class*=language-][data-v-06225672],.theme-mode-light pre[class*=language-][data-v-06225672]{text-shadow:none}}.theme-mode-light pre[class*=language-][data-v-06225672]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-light :not(pre)>code[class*=language-][data-v-06225672],.theme-mode-light pre[class*=language-][data-v-06225672]{background:#f5f2f0}.theme-mode-light :not(pre)>code[class*=language-][data-v-06225672]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-light .token.cdata[data-v-06225672],.theme-mode-light .token.comment[data-v-06225672],.theme-mode-light .token.doctype[data-v-06225672],.theme-mode-light .token.prolog[data-v-06225672]{color:#708090}.theme-mode-light .token.punctuation[data-v-06225672]{color:#999}.theme-mode-light .namespace[data-v-06225672]{opacity:.7}.theme-mode-light .token.boolean[data-v-06225672],.theme-mode-light .token.constant[data-v-06225672],.theme-mode-light .token.deleted[data-v-06225672],.theme-mode-light .token.number[data-v-06225672],.theme-mode-light .token.property[data-v-06225672],.theme-mode-light .token.symbol[data-v-06225672],.theme-mode-light .token.tag[data-v-06225672]{color:#905}.theme-mode-light .token.attr-name[data-v-06225672],.theme-mode-light .token.builtin[data-v-06225672],.theme-mode-light .token.char[data-v-06225672],.theme-mode-light .token.inserted[data-v-06225672],.theme-mode-light .token.selector[data-v-06225672],.theme-mode-light .token.string[data-v-06225672]{color:#690}.theme-mode-light .language-css .token.string[data-v-06225672],.theme-mode-light .style .token.string[data-v-06225672],.theme-mode-light .token.entity[data-v-06225672],.theme-mode-light .token.operator[data-v-06225672],.theme-mode-light .token.url[data-v-06225672]{color:#9a6e3a;background:hsla(0,0%,100%,.5)}.theme-mode-light .token.atrule[data-v-06225672],.theme-mode-light .token.attr-value[data-v-06225672],.theme-mode-light .token.keyword[data-v-06225672]{color:#07a}.theme-mode-light .token.class-name[data-v-06225672],.theme-mode-light .token.function[data-v-06225672]{color:#dd4a68}.theme-mode-light .token.important[data-v-06225672],.theme-mode-light .token.regex[data-v-06225672],.theme-mode-light .token.variable[data-v-06225672]{color:#e90}.theme-mode-light .token.bold[data-v-06225672],.theme-mode-light .token.important[data-v-06225672]{font-weight:700}.theme-mode-light .token.italic[data-v-06225672]{font-style:italic}.theme-mode-light .token.entity[data-v-06225672]{cursor:help}.theme-mode-light div[class*=language-] .highlight-lines .highlighted[data-v-06225672],.theme-mode-light div[class*=language-].line-numbers-mode .highlight-lines .highlighted[data-v-06225672]:before{background-color:hsla(0,0%,78.4%,.4)}.theme-mode-dark[data-v-06225672]{--bodyBg:#1e1e22;--mainBg:#1e1e22;--sidebarBg:rgba(30,30,34,0.8);--blurBg:rgba(30,30,34,0.8);--textColor:#8c8c96;--textLightenColor:#0085ad;--borderColor:#2c2c3a;--codeBg:#252526;--codeColor:#fff}.theme-mode-dark code[class*=language-][data-v-06225672],.theme-mode-dark pre[class*=language-][data-v-06225672]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-dark pre[class*=language-][data-v-06225672]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-dark :not(pre)>code[class*=language-][data-v-06225672],.theme-mode-dark pre[class*=language-][data-v-06225672]{background:#2d2d2d}.theme-mode-dark :not(pre)>code[class*=language-][data-v-06225672]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-dark .token.block-comment[data-v-06225672],.theme-mode-dark .token.cdata[data-v-06225672],.theme-mode-dark .token.comment[data-v-06225672],.theme-mode-dark .token.doctype[data-v-06225672],.theme-mode-dark .token.prolog[data-v-06225672]{color:#999}.theme-mode-dark .token.punctuation[data-v-06225672]{color:#ccc}.theme-mode-dark .token.attr-name[data-v-06225672],.theme-mode-dark .token.deleted[data-v-06225672],.theme-mode-dark .token.namespace[data-v-06225672],.theme-mode-dark .token.tag[data-v-06225672]{color:#e2777a}.theme-mode-dark .token.function-name[data-v-06225672]{color:#6196cc}.theme-mode-dark .token.boolean[data-v-06225672],.theme-mode-dark .token.function[data-v-06225672],.theme-mode-dark .token.number[data-v-06225672]{color:#f08d49}.theme-mode-dark .token.class-name[data-v-06225672],.theme-mode-dark .token.constant[data-v-06225672],.theme-mode-dark .token.property[data-v-06225672],.theme-mode-dark .token.symbol[data-v-06225672]{color:#f8c555}.theme-mode-dark .token.atrule[data-v-06225672],.theme-mode-dark .token.builtin[data-v-06225672],.theme-mode-dark .token.important[data-v-06225672],.theme-mode-dark .token.keyword[data-v-06225672],.theme-mode-dark .token.selector[data-v-06225672]{color:#cc99cd}.theme-mode-dark .token.attr-value[data-v-06225672],.theme-mode-dark .token.char[data-v-06225672],.theme-mode-dark .token.regex[data-v-06225672],.theme-mode-dark .token.string[data-v-06225672],.theme-mode-dark .token.variable[data-v-06225672]{color:#7ec699}.theme-mode-dark .token.entity[data-v-06225672],.theme-mode-dark .token.operator[data-v-06225672],.theme-mode-dark .token.url[data-v-06225672]{color:#67cdcc}.theme-mode-dark .language-css .token.string[data-v-06225672],.theme-mode-dark .style .token.string[data-v-06225672],.theme-mode-dark .token.entity[data-v-06225672],.theme-mode-dark .token.operator[data-v-06225672],.theme-mode-dark .token.url[data-v-06225672]{background:none}.theme-mode-dark .token.bold[data-v-06225672],.theme-mode-dark .token.important[data-v-06225672]{font-weight:700}.theme-mode-dark .token.italic[data-v-06225672]{font-style:italic}.theme-mode-dark .token.entity[data-v-06225672]{cursor:help}.theme-mode-dark .token.inserted[data-v-06225672]{color:green}.theme-mode-read[data-v-06225672]{--bodyBg:#f5f5d5;--mainBg:#f5f5d5;--sidebarBg:rgba(245,245,213,0.8);--blurBg:rgba(245,245,213,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#282c34;--codeColor:#fff}.theme-mode-read code[class*=language-][data-v-06225672],.theme-mode-read pre[class*=language-][data-v-06225672]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-read pre[class*=language-][data-v-06225672]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-read :not(pre)>code[class*=language-][data-v-06225672],.theme-mode-read pre[class*=language-][data-v-06225672]{background:#2d2d2d}.theme-mode-read :not(pre)>code[class*=language-][data-v-06225672]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-read .token.block-comment[data-v-06225672],.theme-mode-read .token.cdata[data-v-06225672],.theme-mode-read .token.comment[data-v-06225672],.theme-mode-read .token.doctype[data-v-06225672],.theme-mode-read .token.prolog[data-v-06225672]{color:#999}.theme-mode-read .token.punctuation[data-v-06225672]{color:#ccc}.theme-mode-read .token.attr-name[data-v-06225672],.theme-mode-read .token.deleted[data-v-06225672],.theme-mode-read .token.namespace[data-v-06225672],.theme-mode-read .token.tag[data-v-06225672]{color:#e2777a}.theme-mode-read .token.function-name[data-v-06225672]{color:#6196cc}.theme-mode-read .token.boolean[data-v-06225672],.theme-mode-read .token.function[data-v-06225672],.theme-mode-read .token.number[data-v-06225672]{color:#f08d49}.theme-mode-read .token.class-name[data-v-06225672],.theme-mode-read .token.constant[data-v-06225672],.theme-mode-read .token.property[data-v-06225672],.theme-mode-read .token.symbol[data-v-06225672]{color:#f8c555}.theme-mode-read .token.atrule[data-v-06225672],.theme-mode-read .token.builtin[data-v-06225672],.theme-mode-read .token.important[data-v-06225672],.theme-mode-read .token.keyword[data-v-06225672],.theme-mode-read .token.selector[data-v-06225672]{color:#cc99cd}.theme-mode-read .token.attr-value[data-v-06225672],.theme-mode-read .token.char[data-v-06225672],.theme-mode-read .token.regex[data-v-06225672],.theme-mode-read .token.string[data-v-06225672],.theme-mode-read .token.variable[data-v-06225672]{color:#7ec699}.theme-mode-read .token.entity[data-v-06225672],.theme-mode-read .token.operator[data-v-06225672],.theme-mode-read .token.url[data-v-06225672]{color:#67cdcc}.theme-mode-read .language-css .token.string[data-v-06225672],.theme-mode-read .style .token.string[data-v-06225672],.theme-mode-read .token.entity[data-v-06225672],.theme-mode-read .token.operator[data-v-06225672],.theme-mode-read .token.url[data-v-06225672]{background:none}.theme-mode-read .token.bold[data-v-06225672],.theme-mode-read .token.important[data-v-06225672]{font-weight:700}.theme-mode-read .token.italic[data-v-06225672]{font-style:italic}.theme-mode-read .token.entity[data-v-06225672]{cursor:help}.theme-mode-read .token.inserted[data-v-06225672]{color:green}.articleInfo-wrap[data-v-06225672]{max-width:860px}.theme-style-line .articleInfo-wrap .articleInfo[data-v-06225672]{padding-top:.5rem}.articleInfo-wrap[data-v-06225672]{position:relative;z-index:1;color:#888}.articleInfo-wrap .articleInfo[data-v-06225672]{overflow:hidden;font-size:.92rem}.articleInfo-wrap .articleInfo .breadcrumbs[data-v-06225672]{margin:0;padding:0;overflow:hidden;display:inline-block;line-height:2rem}@media (max-width:960px){.articleInfo-wrap .articleInfo .breadcrumbs[data-v-06225672]{width:100%}}.articleInfo-wrap .articleInfo .breadcrumbs li[data-v-06225672]{list-style-type:none;float:left;padding-right:5px}.articleInfo-wrap .articleInfo .breadcrumbs li[data-v-06225672]:after{content:"/";margin-left:5px;color:#999}.articleInfo-wrap .articleInfo .breadcrumbs li[data-v-06225672]:last-child:after{content:""}.articleInfo-wrap .articleInfo .breadcrumbs li a[data-v-06225672]{color:#888}.articleInfo-wrap .articleInfo .breadcrumbs li a[data-v-06225672]:before{font-size:.92rem}.articleInfo-wrap .articleInfo .breadcrumbs li a[data-v-06225672]:hover{color:#11a8cd}.articleInfo-wrap .articleInfo .breadcrumbs li .icon-home[data-v-06225672]{text-decoration:none}.articleInfo-wrap .articleInfo .info[data-v-06225672]{float:right;line-height:32px}@media (max-width:960px){.articleInfo-wrap .articleInfo .info[data-v-06225672]{float:left}}.articleInfo-wrap .articleInfo .info div[data-v-06225672]{float:left;margin-left:20px;font-size:.8rem}@media (max-width:960px){.articleInfo-wrap .articleInfo .info div[data-v-06225672]{margin:0 20px 0 0}}.articleInfo-wrap .articleInfo .info div[data-v-06225672]:before{margin-right:3px}.articleInfo-wrap .articleInfo .info div a[data-v-06225672]{color:#888}.articleInfo-wrap .articleInfo .info div a[data-v-06225672]:hover{text-decoration:none}.articleInfo-wrap .articleInfo .info div a.beLink[data-v-06225672]:hover{color:#11a8cd;text-decoration:underline}.theme-mode-light[data-v-2cf874fa]{--bodyBg:#f4f4f4;--customBlockBg:#f1f1f1;--textColor:#00323c;--borderColor:rgba(0,0,0,0.12)}.theme-mode-dark[data-v-2cf874fa]{--bodyBg:#27272b;--customBlockBg:#27272b;--textColor:#9b9baa;--borderColor:#30363d}.theme-mode-read[data-v-2cf874fa]{--bodyBg:#ececcc;--customBlockBg:#ececcc;--textColor:#704214;--textLightenColor:#963}.theme-style-line.theme-mode-light[data-v-2cf874fa]{--bodyBg:#fff}.theme-style-line.theme-mode-dark[data-v-2cf874fa]{--bodyBg:#1e1e22}.theme-style-line.theme-mode-read[data-v-2cf874fa]{--bodyBg:#f5f5d5}.theme-mode-light[data-v-2cf874fa]{--bodyBg:#fff;--mainBg:#fff;--sidebarBg:hsla(0,0%,100%,0.8);--blurBg:hsla(0,0%,100%,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#f6f6f6;--codeColor:#525252}.theme-mode-light code[class*=language-][data-v-2cf874fa],.theme-mode-light pre[class*=language-][data-v-2cf874fa]{color:#000;background:none;text-shadow:0 1px #fff;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-light code[class*=language-][data-v-2cf874fa]::-moz-selection,.theme-mode-light code[class*=language-][data-v-2cf874fa] ::-moz-selection,.theme-mode-light pre[class*=language-][data-v-2cf874fa]::-moz-selection,.theme-mode-light pre[class*=language-][data-v-2cf874fa] ::-moz-selection{text-shadow:none;background:#b3d4fc}.theme-mode-light code[class*=language-][data-v-2cf874fa]::selection,.theme-mode-light code[class*=language-][data-v-2cf874fa] ::selection,.theme-mode-light pre[class*=language-][data-v-2cf874fa]::selection,.theme-mode-light pre[class*=language-][data-v-2cf874fa] ::selection{text-shadow:none;background:#b3d4fc}@media print{.theme-mode-light code[class*=language-][data-v-2cf874fa],.theme-mode-light pre[class*=language-][data-v-2cf874fa]{text-shadow:none}}.theme-mode-light pre[class*=language-][data-v-2cf874fa]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-light :not(pre)>code[class*=language-][data-v-2cf874fa],.theme-mode-light pre[class*=language-][data-v-2cf874fa]{background:#f5f2f0}.theme-mode-light :not(pre)>code[class*=language-][data-v-2cf874fa]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-light .token.cdata[data-v-2cf874fa],.theme-mode-light .token.comment[data-v-2cf874fa],.theme-mode-light .token.doctype[data-v-2cf874fa],.theme-mode-light .token.prolog[data-v-2cf874fa]{color:#708090}.theme-mode-light .token.punctuation[data-v-2cf874fa]{color:#999}.theme-mode-light .namespace[data-v-2cf874fa]{opacity:.7}.theme-mode-light .token.boolean[data-v-2cf874fa],.theme-mode-light .token.constant[data-v-2cf874fa],.theme-mode-light .token.deleted[data-v-2cf874fa],.theme-mode-light .token.number[data-v-2cf874fa],.theme-mode-light .token.property[data-v-2cf874fa],.theme-mode-light .token.symbol[data-v-2cf874fa],.theme-mode-light .token.tag[data-v-2cf874fa]{color:#905}.theme-mode-light .token.attr-name[data-v-2cf874fa],.theme-mode-light .token.builtin[data-v-2cf874fa],.theme-mode-light .token.char[data-v-2cf874fa],.theme-mode-light .token.inserted[data-v-2cf874fa],.theme-mode-light .token.selector[data-v-2cf874fa],.theme-mode-light .token.string[data-v-2cf874fa]{color:#690}.theme-mode-light .language-css .token.string[data-v-2cf874fa],.theme-mode-light .style .token.string[data-v-2cf874fa],.theme-mode-light .token.entity[data-v-2cf874fa],.theme-mode-light .token.operator[data-v-2cf874fa],.theme-mode-light .token.url[data-v-2cf874fa]{color:#9a6e3a;background:hsla(0,0%,100%,.5)}.theme-mode-light .token.atrule[data-v-2cf874fa],.theme-mode-light .token.attr-value[data-v-2cf874fa],.theme-mode-light .token.keyword[data-v-2cf874fa]{color:#07a}.theme-mode-light .token.class-name[data-v-2cf874fa],.theme-mode-light .token.function[data-v-2cf874fa]{color:#dd4a68}.theme-mode-light .token.important[data-v-2cf874fa],.theme-mode-light .token.regex[data-v-2cf874fa],.theme-mode-light .token.variable[data-v-2cf874fa]{color:#e90}.theme-mode-light .token.bold[data-v-2cf874fa],.theme-mode-light .token.important[data-v-2cf874fa]{font-weight:700}.theme-mode-light .token.italic[data-v-2cf874fa]{font-style:italic}.theme-mode-light .token.entity[data-v-2cf874fa]{cursor:help}.theme-mode-light div[class*=language-] .highlight-lines .highlighted[data-v-2cf874fa],.theme-mode-light div[class*=language-].line-numbers-mode .highlight-lines .highlighted[data-v-2cf874fa]:before{background-color:hsla(0,0%,78.4%,.4)}.theme-mode-dark[data-v-2cf874fa]{--bodyBg:#1e1e22;--mainBg:#1e1e22;--sidebarBg:rgba(30,30,34,0.8);--blurBg:rgba(30,30,34,0.8);--textColor:#8c8c96;--textLightenColor:#0085ad;--borderColor:#2c2c3a;--codeBg:#252526;--codeColor:#fff}.theme-mode-dark code[class*=language-][data-v-2cf874fa],.theme-mode-dark pre[class*=language-][data-v-2cf874fa]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-dark pre[class*=language-][data-v-2cf874fa]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-dark :not(pre)>code[class*=language-][data-v-2cf874fa],.theme-mode-dark pre[class*=language-][data-v-2cf874fa]{background:#2d2d2d}.theme-mode-dark :not(pre)>code[class*=language-][data-v-2cf874fa]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-dark .token.block-comment[data-v-2cf874fa],.theme-mode-dark .token.cdata[data-v-2cf874fa],.theme-mode-dark .token.comment[data-v-2cf874fa],.theme-mode-dark .token.doctype[data-v-2cf874fa],.theme-mode-dark .token.prolog[data-v-2cf874fa]{color:#999}.theme-mode-dark .token.punctuation[data-v-2cf874fa]{color:#ccc}.theme-mode-dark .token.attr-name[data-v-2cf874fa],.theme-mode-dark .token.deleted[data-v-2cf874fa],.theme-mode-dark .token.namespace[data-v-2cf874fa],.theme-mode-dark .token.tag[data-v-2cf874fa]{color:#e2777a}.theme-mode-dark .token.function-name[data-v-2cf874fa]{color:#6196cc}.theme-mode-dark .token.boolean[data-v-2cf874fa],.theme-mode-dark .token.function[data-v-2cf874fa],.theme-mode-dark .token.number[data-v-2cf874fa]{color:#f08d49}.theme-mode-dark .token.class-name[data-v-2cf874fa],.theme-mode-dark .token.constant[data-v-2cf874fa],.theme-mode-dark .token.property[data-v-2cf874fa],.theme-mode-dark .token.symbol[data-v-2cf874fa]{color:#f8c555}.theme-mode-dark .token.atrule[data-v-2cf874fa],.theme-mode-dark .token.builtin[data-v-2cf874fa],.theme-mode-dark .token.important[data-v-2cf874fa],.theme-mode-dark .token.keyword[data-v-2cf874fa],.theme-mode-dark .token.selector[data-v-2cf874fa]{color:#cc99cd}.theme-mode-dark .token.attr-value[data-v-2cf874fa],.theme-mode-dark .token.char[data-v-2cf874fa],.theme-mode-dark .token.regex[data-v-2cf874fa],.theme-mode-dark .token.string[data-v-2cf874fa],.theme-mode-dark .token.variable[data-v-2cf874fa]{color:#7ec699}.theme-mode-dark .token.entity[data-v-2cf874fa],.theme-mode-dark .token.operator[data-v-2cf874fa],.theme-mode-dark .token.url[data-v-2cf874fa]{color:#67cdcc}.theme-mode-dark .language-css .token.string[data-v-2cf874fa],.theme-mode-dark .style .token.string[data-v-2cf874fa],.theme-mode-dark .token.entity[data-v-2cf874fa],.theme-mode-dark .token.operator[data-v-2cf874fa],.theme-mode-dark .token.url[data-v-2cf874fa]{background:none}.theme-mode-dark .token.bold[data-v-2cf874fa],.theme-mode-dark .token.important[data-v-2cf874fa]{font-weight:700}.theme-mode-dark .token.italic[data-v-2cf874fa]{font-style:italic}.theme-mode-dark .token.entity[data-v-2cf874fa]{cursor:help}.theme-mode-dark .token.inserted[data-v-2cf874fa]{color:green}.theme-mode-read[data-v-2cf874fa]{--bodyBg:#f5f5d5;--mainBg:#f5f5d5;--sidebarBg:rgba(245,245,213,0.8);--blurBg:rgba(245,245,213,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#282c34;--codeColor:#fff}.theme-mode-read code[class*=language-][data-v-2cf874fa],.theme-mode-read pre[class*=language-][data-v-2cf874fa]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-read pre[class*=language-][data-v-2cf874fa]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-read :not(pre)>code[class*=language-][data-v-2cf874fa],.theme-mode-read pre[class*=language-][data-v-2cf874fa]{background:#2d2d2d}.theme-mode-read :not(pre)>code[class*=language-][data-v-2cf874fa]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-read .token.block-comment[data-v-2cf874fa],.theme-mode-read .token.cdata[data-v-2cf874fa],.theme-mode-read .token.comment[data-v-2cf874fa],.theme-mode-read .token.doctype[data-v-2cf874fa],.theme-mode-read .token.prolog[data-v-2cf874fa]{color:#999}.theme-mode-read .token.punctuation[data-v-2cf874fa]{color:#ccc}.theme-mode-read .token.attr-name[data-v-2cf874fa],.theme-mode-read .token.deleted[data-v-2cf874fa],.theme-mode-read .token.namespace[data-v-2cf874fa],.theme-mode-read .token.tag[data-v-2cf874fa]{color:#e2777a}.theme-mode-read .token.function-name[data-v-2cf874fa]{color:#6196cc}.theme-mode-read .token.boolean[data-v-2cf874fa],.theme-mode-read .token.function[data-v-2cf874fa],.theme-mode-read .token.number[data-v-2cf874fa]{color:#f08d49}.theme-mode-read .token.class-name[data-v-2cf874fa],.theme-mode-read .token.constant[data-v-2cf874fa],.theme-mode-read .token.property[data-v-2cf874fa],.theme-mode-read .token.symbol[data-v-2cf874fa]{color:#f8c555}.theme-mode-read .token.atrule[data-v-2cf874fa],.theme-mode-read .token.builtin[data-v-2cf874fa],.theme-mode-read .token.important[data-v-2cf874fa],.theme-mode-read .token.keyword[data-v-2cf874fa],.theme-mode-read .token.selector[data-v-2cf874fa]{color:#cc99cd}.theme-mode-read .token.attr-value[data-v-2cf874fa],.theme-mode-read .token.char[data-v-2cf874fa],.theme-mode-read .token.regex[data-v-2cf874fa],.theme-mode-read .token.string[data-v-2cf874fa],.theme-mode-read .token.variable[data-v-2cf874fa]{color:#7ec699}.theme-mode-read .token.entity[data-v-2cf874fa],.theme-mode-read .token.operator[data-v-2cf874fa],.theme-mode-read .token.url[data-v-2cf874fa]{color:#67cdcc}.theme-mode-read .language-css .token.string[data-v-2cf874fa],.theme-mode-read .style .token.string[data-v-2cf874fa],.theme-mode-read .token.entity[data-v-2cf874fa],.theme-mode-read .token.operator[data-v-2cf874fa],.theme-mode-read .token.url[data-v-2cf874fa]{background:none}.theme-mode-read .token.bold[data-v-2cf874fa],.theme-mode-read .token.important[data-v-2cf874fa]{font-weight:700}.theme-mode-read .token.italic[data-v-2cf874fa]{font-style:italic}.theme-mode-read .token.entity[data-v-2cf874fa]{cursor:help}.theme-mode-read .token.inserted[data-v-2cf874fa]{color:green}.theme-vdoing-content[data-v-2cf874fa]{margin-bottom:3.6rem}.title-tag[data-v-2cf874fa]{border:1px solid #ff5722;color:#ff5722;font-size:.8rem;padding:0 .35rem;border-radius:.2rem;margin-left:0;transform:translateY(-.05rem);display:inline-block}dd[data-v-2cf874fa],dl[data-v-2cf874fa]{margin:0}.column-wrapper[data-v-2cf874fa]{margin-top:1rem;display:flex;padding-bottom:2rem;border-bottom:1px solid var(--borderColor)}.column-wrapper img[data-v-2cf874fa]{width:80px;height:80px;border-radius:2px;margin-right:1rem}.column-wrapper .column-info .title[data-v-2cf874fa]{font-size:1.6rem}.column-wrapper .column-info .description[data-v-2cf874fa]{color:var(--textColor);opacity:.8;margin:.5rem 0}.catalogue-wrapper .catalogue-title[data-v-2cf874fa]{font-size:1.45rem;margin:2rem 0}.catalogue-wrapper .catalogue-content dl[data-v-2cf874fa]{margin-bottom:1.8rem}.catalogue-wrapper .catalogue-content dl.inline[data-v-2cf874fa]{display:inline-block;width:50%;margin-bottom:1rem}@media (max-width:419px){.catalogue-wrapper .catalogue-content dl.inline[data-v-2cf874fa]{width:100%}}.catalogue-wrapper .catalogue-content dl.inline a[data-v-2cf874fa]{width:100%}.catalogue-wrapper .catalogue-content dl:not(.inline) dt[data-v-2cf874fa]{margin-top:-3.6rem;padding-top:3.6rem}.catalogue-wrapper .catalogue-content dl dt[data-v-2cf874fa]{font-size:1.1rem}.catalogue-wrapper .catalogue-content dl dt:hover .header-anchor[data-v-2cf874fa]{opacity:1}.catalogue-wrapper .catalogue-content dl dd[data-v-2cf874fa]{margin-top:.7rem;margin-left:1rem}.catalogue-wrapper .catalogue-content dl dd a[data-v-2cf874fa]:not(.header-anchor){margin-bottom:.5rem;display:inline-block;width:50%}.catalogue-wrapper .catalogue-content dl dd a[data-v-2cf874fa]:not(.header-anchor):hover{color:#ff5722;text-decoration:none}@media (max-width:720px){.catalogue-wrapper .catalogue-content dl dd a[data-v-2cf874fa]:not(.header-anchor){width:100%}}.catalogue-wrapper .catalogue-content dl .sub-cat-wrap[data-v-2cf874fa]{margin:5px 0 8px;font-size:.95rem}.catalogue-wrapper .catalogue-content dl .sub-cat-wrap>a[data-v-2cf874fa]{padding-left:1rem;box-sizing:border-box}.catalogue-wrapper .catalogue-content dl .sub-cat-wrap .sub-title[data-v-2cf874fa]{margin-top:-3.6rem;padding-top:3.6rem;margin-bottom:6px;font-size:1rem}.catalogue-wrapper .catalogue-content dl .sub-cat-wrap:hover .header-anchor[data-v-2cf874fa]{opacity:1}.theme-style-line .right-menu-wrapper .right-menu-margin{border-left:1px solid var(--borderColor)}.right-menu-wrapper{width:230px;float:right;margin-right:-285px;position:sticky;top:0;font-size:.8rem}.right-menu-wrapper .right-menu-margin{margin-top:4.6rem;border-radius:3px;overflow:hidden}.right-menu-wrapper .right-menu-title{padding:10px 15px 0;background:var(--mainBg);font-size:1rem}.right-menu-wrapper .right-menu-title:after{content:"";display:block;width:100%;height:1px;background:var(--borderColor);margin-top:10px}.right-menu-wrapper .right-menu-content{max-height:80vh;position:relative;overflow:hidden;background:var(--mainBg);padding:4px 3px 4px 0}.right-menu-wrapper .right-menu-content::-webkit-scrollbar{width:3px;height:3px}.right-menu-wrapper .right-menu-content::-webkit-scrollbar-track-piece{background:none}.right-menu-wrapper .right-menu-content::-webkit-scrollbar-thumb:vertical{background-color:hsla(0,0%,49%,.3)}.right-menu-wrapper .right-menu-content:hover{overflow-y:auto;padding-right:0}.right-menu-wrapper .right-menu-content .right-menu-item{padding:4px 15px;overflow:hidden;white-space:nowrap;text-overflow:ellipsis;position:relative}.right-menu-wrapper .right-menu-content .right-menu-item.level2{font-size:.8rem}.right-menu-wrapper .right-menu-content .right-menu-item.level3{padding-left:27px}.right-menu-wrapper .right-menu-content .right-menu-item.level4{padding-left:37px}.right-menu-wrapper .right-menu-content .right-menu-item.level5{padding-left:47px}.right-menu-wrapper .right-menu-content .right-menu-item.level6{padding-left:57px}.right-menu-wrapper .right-menu-content .right-menu-item.active:before{content:"";position:absolute;top:5px;left:0;width:3px;height:14px;background:#11a8cd;border-radius:0 4px 4px 0}.right-menu-wrapper .right-menu-content .right-menu-item.active a{color:#11a8cd;opacity:1}.right-menu-wrapper .right-menu-content .right-menu-item a{color:var(--textColor);opacity:.75;display:inline-block;width:100%;overflow:hidden;white-space:nowrap;text-overflow:ellipsis}.right-menu-wrapper .right-menu-content .right-menu-item a:hover{opacity:1}.right-menu-wrapper .right-menu-content:hover{color:#11a8cd}.page>*{max-width:860px;margin:0 auto;padding:1rem 2.5rem 2rem}.page>:not(.footer){background:var(--mainBg);box-shadow:0 1px 2px 0 rgba(0,0,0,.1);margin-bottom:1rem}@media (min-width:940px){.page>:not(.footer){border-radius:2px}}@media (max-width:959px){.page>*{padding:1rem 2rem}}@media (max-width:419px){.page>*{padding:1rem 1.5rem}}.page{padding-bottom:2rem;display:block}@media (max-width:719px){.page{padding-top:3.6rem}}@media (min-width:719px){.page{padding-top:5.1rem}}@media (min-width:719px){.theme-style-line .page{padding-top:3.6rem}}.theme-style-line .page>:not(.footer){box-shadow:0 0}@media (min-width:720px){.theme-style-line .page .placeholder{height:1.2rem}}.theme-vdoing-wrapper .content-wrapper{position:relative}.theme-vdoing-wrapper h1 .title-tag{height:1.5rem;line-height:1.5rem;border:1px solid #ff5722;color:#ff5722;font-size:1rem;padding:0 .4rem;border-radius:.2rem;margin-left:.5rem;transform:translateY(-.25rem);display:inline-block}.theme-vdoing-wrapper h1 img{margin-bottom:-.2rem;margin-right:.2rem;max-width:2.2rem;max-height:2.2rem}.theme-vdoing-wrapper{--linesColor:rgba(50,0,0,0.05)}.theme-vdoing-wrapper.bg-style-1{background-image:linear-gradient(90deg,var(--linesColor) 3%,transparent 0),linear-gradient(0deg,var(--linesColor) 3%,transparent 0);background-position:50%;background-size:20px 20px}.theme-vdoing-wrapper.bg-style-2{background-image:repeating-linear-gradient(0,var(--linesColor),var(--linesColor) 1px,transparent 0,transparent 50%);background-size:30px 30px}.theme-vdoing-wrapper.bg-style-3{background-image:repeating-linear-gradient(90deg,var(--linesColor),var(--linesColor) 1px,transparent 0,transparent 50%);background-size:30px 30px}.theme-vdoing-wrapper.bg-style-4{background-image:repeating-linear-gradient(-45deg,var(--linesColor),var(--linesColor) 1px,transparent 0,transparent 50%);background-size:20px 20px}.theme-vdoing-wrapper.bg-style-5{background-image:repeating-linear-gradient(45deg,var(--linesColor),var(--linesColor) 1px,transparent 0,transparent 50%);background-size:20px 20px}.theme-vdoing-wrapper.bg-style-6{background-image:radial-gradient(var(--linesColor) 1px,transparent 0);background-size:10px 10px}.theme-mode-dark .theme-vdoing-wrapper{--linesColor:hsla(0,0%,49%,0.05)}@media (min-width:720px) and (max-width:1279px){.have-rightmenu .page{padding-right:.8rem!important}}@media (max-width:1279px){.have-rightmenu .right-menu-wrapper{display:none}}@media (min-width:1280px){.have-rightmenu .sidebar .sidebar-sub-headers{display:none}}.theme-container.only-sidebarItem:not(.have-rightmenu) .sidebar,.theme-container.only-sidebarItem:not(.have-rightmenu) .sidebar-button{display:none}@media (min-width:720px){.theme-container.only-sidebarItem:not(.have-rightmenu) .page{padding-left:.8rem!important}}@media (max-width:719px){.theme-container.only-sidebarItem:not(.have-rightmenu) .page{padding-left:0!important}.theme-container.only-sidebarItem:not(.have-rightmenu) .sidebar,.theme-container.only-sidebarItem:not(.have-rightmenu) .sidebar-button{display:block}}@media (min-width:720px) and (max-width:1279px){.theme-container.only-sidebarItem.have-rightmenu .sidebar,.theme-container.only-sidebarItem.have-rightmenu .sidebar-button{display:block}}@media (min-width:1280px){.theme-container.only-sidebarItem.have-rightmenu .sidebar,.theme-container.only-sidebarItem.have-rightmenu .sidebar-button{display:none}}.categories-page .categories-wrapper{position:sticky;top:4.5rem;max-height:calc(100vh - 10rem);min-height:4.2rem}@media (max-width:719px){.categories-page .categories-wrapper{display:none}}.categories-page .categories-wrapper .categories{padding-right:.5rem;max-height:calc(100vh - 14rem);min-height:2.2rem;overflow-y:auto;transition:all .2s;position:relative}.categories-page .categories-wrapper .categories::-webkit-scrollbar-track-piece{background-color:rgba(0,0,0,.05)}.categories-page .categories-wrapper .categories::-webkit-scrollbar-thumb:vertical{background-color:rgba(0,0,0,.15)}.categories-page .categories-wrapper .categories:hover::-webkit-scrollbar-track-piece{background-color:rgba(0,0,0,.1)}.categories-page .categories-wrapper .categories:hover::-webkit-scrollbar-thumb:vertical{background-color:rgba(0,0,0,.25)}.categories-page .main-left .categories-wrapper{position:relative;top:0;padding:.9rem 1.5rem;margin-bottom:.9rem;max-height:15rem;border-radius:0;display:none}@media (max-width:719px){.categories-page .main-left .categories-wrapper{display:block}}.categories-page .main-left .categories-wrapper .categories{max-height:12.3rem}@media (max-width:719px){.theme-style-line .categories-page .main-left .categories-wrapper{margin-top:-.91rem;margin-bottom:-1px;padding:.9rem .2rem .5rem}}.tags-page .tags-wrapper{position:sticky;top:4.5rem;max-height:calc(100vh - 10rem);min-height:4.2rem}@media (max-width:719px){.tags-page .tags-wrapper{display:none}}.tags-page .tags-wrapper .tags{max-height:calc(100vh - 14rem);min-height:2.2rem;overflow-x:hidden;overflow-y:auto;transition:all .2s}.tags-page .tags-wrapper .tags::-webkit-scrollbar-track-piece{background-color:rgba(0,0,0,.05)}.tags-page .tags-wrapper .tags::-webkit-scrollbar-thumb:vertical{background-color:rgba(0,0,0,.15)}.tags-page .tags-wrapper .tags:hover::-webkit-scrollbar-track-piece{background-color:rgba(0,0,0,.1)}.tags-page .tags-wrapper .tags:hover::-webkit-scrollbar-thumb:vertical{background-color:rgba(0,0,0,.25)}.tags-page .main-left .tags-wrapper{position:relative;top:0;padding:.9rem 1.5rem;margin-bottom:.9rem;max-height:15rem;border-radius:0;display:none}@media (max-width:719px){.tags-page .main-left .tags-wrapper{display:block}}.tags-page .main-left .tags-wrapper .tags{max-height:11.5rem}@media (max-width:719px){.theme-style-line .tags-page .main-left .tags-wrapper{margin-top:-.91rem;margin-bottom:-1px}}.archives-page .theme-vdoing-wrapper{max-width:860px;margin:0 auto;padding:1rem 2.5rem 2rem}.archives-page .theme-vdoing-wrapper:not(.footer){background:var(--mainBg);box-shadow:0 1px 2px 0 rgba(0,0,0,.1);margin-bottom:1rem}@media (min-width:940px){.archives-page .theme-vdoing-wrapper:not(.footer){border-radius:2px}}@media (max-width:959px){.archives-page .theme-vdoing-wrapper{padding:1rem 2rem}}@media (max-width:419px){.archives-page .theme-vdoing-wrapper{padding:1rem 1.5rem}}.theme-style-line .archives-page .theme-vdoing-wrapper{box-shadow:0 0}.archives-page .theme-vdoing-wrapper{position:relative}@media (min-width:940px){.archives-page .theme-vdoing-wrapper{margin-top:1.5rem!important}}.archives-page .theme-vdoing-wrapper .count{text-align:right;margin-top:-2.5rem;font-size:.85rem;opacity:.8}.archives-page .theme-vdoing-wrapper li,.archives-page .theme-vdoing-wrapper ul{margin:0;padding:0}.archives-page .theme-vdoing-wrapper ul{margin-top:2rem}.archives-page .theme-vdoing-wrapper li{list-style:none}.archives-page .theme-vdoing-wrapper li.year{position:sticky;top:3.6rem;background:var(--mainBg);z-index:1}.archives-page .theme-vdoing-wrapper li.year:not(:first-child){margin-top:3.5rem}.archives-page .theme-vdoing-wrapper li h2{margin-bottom:.8rem;font-weight:400;padding:.5rem 0}.archives-page .theme-vdoing-wrapper li h2 span{font-size:.85rem;font-weight:300;float:right;margin-top:1rem}.archives-page .theme-vdoing-wrapper li a{display:block;color:var(--textColor);transition:padding .3s;padding:.5rem 2rem;line-height:1.2rem}.archives-page .theme-vdoing-wrapper li a:hover{padding-left:2.5rem;color:#11a8cd;background:#f9f9f9}@media (max-width:940px){.archives-page .theme-vdoing-wrapper li a{padding:.5rem 1rem;font-weight:400}.archives-page .theme-vdoing-wrapper li a:hover{padding-left:1.5rem}}.archives-page .theme-vdoing-wrapper li a span.date{opacity:.6;font-size:.85rem;font-weight:400;margin-right:.3rem}.archives-page .theme-vdoing-wrapper li a .title-tag{border:1px solid #ff5722;color:#ff5722;font-size:.8rem;padding:0 .35rem;border-radius:.2rem;margin-left:0;transform:translateY(-.05rem);display:inline-block}.archives-page .theme-vdoing-wrapper .loadmore{text-align:center;margin-top:1rem;opacity:.5}.theme-mode-dark .archives-page .theme-vdoing-wrapper li a:hover,.theme-mode-read .archives-page .theme-vdoing-wrapper li a:hover{background:var(--customBlockBg)}.hide-navbar .archives-page .theme-vdoing-wrapper li.year{top:0}.sidebar-group .sidebar-group{padding-left:.5em}.sidebar-group:not(.collapsable) .sidebar-heading:not(.clickable){cursor:auto;color:inherit}.sidebar-group.is-sub-group{padding-left:0}.sidebar-group.is-sub-group>.sidebar-heading{font-size:1.01em;line-height:1.4;font-weight:700;padding-left:2rem}.sidebar-group.is-sub-group>.sidebar-group-items{padding-left:1rem}.sidebar-group.is-sub-group>.sidebar-group-items>li>.sidebar-link{font-size:.98em;border-left:none}.sidebar-group.depth-2>.sidebar-heading{border-left:none}.sidebar-heading{color:var(--textColor);transition:color .15s ease;cursor:pointer;font-size:1.1em;font-weight:700;padding:.35rem 1.5rem .35rem 1.25rem;width:100%;box-sizing:border-box;margin:0;border-left:.25rem solid transparent}.sidebar-heading.open,.sidebar-heading:hover{color:inherit}.sidebar-heading .arrow{position:relative;top:-.12em;left:.5em}.sidebar-heading.clickable.active{font-weight:600;color:#11a8cd;border-left-color:#11a8cd}.sidebar-heading.clickable:hover{color:#11a8cd}.sidebar-group-items{transition:height .1s ease-out;font-size:.95em;overflow:hidden}.sidebar .sidebar-sub-headers{padding-left:1rem;font-size:.95em}.sidebar .sidebar-sub-headers .level4{padding-left:.2rem}.sidebar .sidebar-sub-headers .level5{padding-left:.4rem}.sidebar .sidebar-sub-headers .level6{padding-left:.6rem}a.sidebar-link{font-size:1em;font-weight:400;display:inline-block;color:var(--textColor);border-left:.25rem solid transparent;padding:.35rem 1rem .35rem 1.25rem;line-height:1.4;width:100%;box-sizing:border-box}a.sidebar-link:hover{color:#11a8cd}a.sidebar-link.active{font-weight:600;color:#11a8cd;border-left-color:#11a8cd}.sidebar-group a.sidebar-link{padding-left:2rem}.sidebar-sub-headers a.sidebar-link{padding-top:.25rem;padding-bottom:.25rem;border-left:none}.sidebar-sub-headers a.sidebar-link.active{font-weight:500}.sidebar ul{padding:0;margin:0;list-style-type:none}.sidebar a{display:inline-block}.sidebar .nav-links{display:none;border-bottom:1px solid var(--borderColor);padding:.5rem 0 .75rem}.sidebar .nav-links a{font-weight:600}.sidebar .nav-links .nav-item,.sidebar .nav-links .repo-link{display:block;line-height:1.25rem;font-size:1.1em;padding:.5rem 0 .5rem 1.5rem}.sidebar>.sidebar-links{padding:1.5rem 0}.sidebar>.sidebar-links>li>a.sidebar-link{font-size:1.1em;line-height:1.7;font-weight:700}.sidebar>.sidebar-links>li:not(:first-child){margin-top:.75rem}.sidebar .blogger{display:none;border-bottom:1px solid var(--borderColor)}.sidebar .blogger img{width:60px;height:60px;border-radius:5px;margin:.75rem 1rem}.sidebar .blogger .blogger-info{flex:1;padding:0 .3rem .3rem 0}.sidebar .blogger .blogger-info h3{margin:.95rem 0 .6rem;font-size:1.1rem}.sidebar .blogger .blogger-info .icons .iconfont{font-size:1.2rem;padding-right:.6rem;color:#777}.sidebar .sidebar-slot{margin-bottom:-.5rem;font-size:.85rem}.sidebar .sidebar-slot.sidebar-slot-top{padding:1.5rem 1.5rem 0}.sidebar .sidebar-slot.sidebar-slot-bottom{padding:0 1.5rem 1.5rem}@media (max-width:719px){.sidebar .blogger{display:flex}.sidebar .nav-links{display:block}.sidebar .nav-links .dropdown-wrapper .nav-dropdown .dropdown-item a.router-link-active:after{top:calc(1rem - 2px)}.sidebar>.sidebar-links{padding:1rem 0}}.yellowBorder{border-radius:5px;box-shadow:0 0 15px #ffe089!important}.buttons{position:fixed;right:2rem;bottom:2.5rem;z-index:11}@media (max-width:959px){.buttons{right:1rem;bottom:1.5rem}}.buttons .button{width:2.2rem;height:2.2rem;line-height:2.2rem;border-radius:50%;box-shadow:0 2px 6px rgba(0,0,0,.15);margin-top:.9rem;text-align:center;cursor:pointer;transition:all .5s;background:var(--blurBg)}.buttons .button.hover{background:#11a8cd;box-shadow:0 0 15px #11a8cd}.buttons .button.hover:before{color:#fff}@media (any-hover:hover){.buttons .button:hover{background:#11a8cd;box-shadow:0 0 15px #11a8cd}.buttons .button:hover:before{color:#fff}}.buttons .button .select-box{margin:0;padding:.8rem 0;position:absolute;bottom:0;right:1.5rem;background:var(--mainBg);border:1px solid var(--borderColor);width:120px;border-radius:6px;box-shadow:0 0 15px hsla(0,0%,100%,.2)}.buttons .button .select-box li{list-style:none;line-height:2rem;font-size:.95rem}.buttons .button .select-box li:hover{color:#11a8cd}.buttons .button .select-box li.active{background-color:hsla(0,0%,58.8%,.2);color:#11a8cd}.mode-enter-active,.mode-leave-active{transition:all .3s}.mode-enter,.mode-leave-to{opacity:0;transform:scale(.8)}.fade-enter-active,.fade-leave-active{transition:opacity .2s}.fade-enter,.fade-leave-to{opacity:0}.footer{padding:5rem 1.5rem 2.5rem;text-align:center;color:#666;box-sizing:border-box;font-size:.85rem;transition:all .2s ease}.footer>span{line-height:1.5rem}.footer .icons{margin-bottom:12px}.footer .icons .iconfont{padding:0 10px;font-size:1.3rem}.footer a{color:inherit}.footer a:hover{color:#11a8cd}@media (min-width:720px){.sidebar-open .footer{width:auto;padding-left:19.5rem}}@media (min-width:1520px){.have-rightmenu .footer{padding-right:231.5px}}.no-sidebar .footer{width:auto;padding-left:1.5rem}.body-bg{position:fixed;left:0;top:0;z-index:-999999;height:100vh;width:100vw;transition:background .5s}.theme-mode-light{--bodyBg:#f4f4f4;--customBlockBg:#f1f1f1;--textColor:#00323c;--borderColor:rgba(0,0,0,0.12)}.theme-mode-dark{--bodyBg:#27272b;--customBlockBg:#27272b;--textColor:#9b9baa;--borderColor:#30363d}.theme-mode-read{--bodyBg:#ececcc;--customBlockBg:#ececcc;--textColor:#704214;--textLightenColor:#963}.theme-style-line.theme-mode-light{--bodyBg:#fff}.theme-style-line.theme-mode-dark{--bodyBg:#1e1e22}.theme-style-line.theme-mode-read{--bodyBg:#f5f5d5}.theme-mode-light{--bodyBg:#fff;--mainBg:#fff;--sidebarBg:hsla(0,0%,100%,0.8);--blurBg:hsla(0,0%,100%,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#f6f6f6;--codeColor:#525252}.theme-mode-light code[class*=language-],.theme-mode-light pre[class*=language-]{color:#000;background:none;text-shadow:0 1px #fff;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-light code[class*=language-]::-moz-selection,.theme-mode-light code[class*=language-] ::-moz-selection,.theme-mode-light pre[class*=language-]::-moz-selection,.theme-mode-light pre[class*=language-] ::-moz-selection{text-shadow:none;background:#b3d4fc}.theme-mode-light code[class*=language-]::selection,.theme-mode-light code[class*=language-] ::selection,.theme-mode-light pre[class*=language-]::selection,.theme-mode-light pre[class*=language-] ::selection{text-shadow:none;background:#b3d4fc}@media print{.theme-mode-light code[class*=language-],.theme-mode-light pre[class*=language-]{text-shadow:none}}.theme-mode-light pre[class*=language-]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-light :not(pre)>code[class*=language-],.theme-mode-light pre[class*=language-]{background:#f5f2f0}.theme-mode-light :not(pre)>code[class*=language-]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-light .token.cdata,.theme-mode-light .token.comment,.theme-mode-light .token.doctype,.theme-mode-light .token.prolog{color:#708090}.theme-mode-light .token.punctuation{color:#999}.theme-mode-light .namespace{opacity:.7}.theme-mode-light .token.boolean,.theme-mode-light .token.constant,.theme-mode-light .token.deleted,.theme-mode-light .token.number,.theme-mode-light .token.property,.theme-mode-light .token.symbol,.theme-mode-light .token.tag{color:#905}.theme-mode-light .token.attr-name,.theme-mode-light .token.builtin,.theme-mode-light .token.char,.theme-mode-light .token.inserted,.theme-mode-light .token.selector,.theme-mode-light .token.string{color:#690}.theme-mode-light .language-css .token.string,.theme-mode-light .style .token.string,.theme-mode-light .token.entity,.theme-mode-light .token.operator,.theme-mode-light .token.url{color:#9a6e3a;background:hsla(0,0%,100%,.5)}.theme-mode-light .token.atrule,.theme-mode-light .token.attr-value,.theme-mode-light .token.keyword{color:#07a}.theme-mode-light .token.class-name,.theme-mode-light .token.function{color:#dd4a68}.theme-mode-light .token.important,.theme-mode-light .token.regex,.theme-mode-light .token.variable{color:#e90}.theme-mode-light .token.bold,.theme-mode-light .token.important{font-weight:700}.theme-mode-light .token.italic{font-style:italic}.theme-mode-light .token.entity{cursor:help}.theme-mode-light div[class*=language-] .highlight-lines .highlighted,.theme-mode-light div[class*=language-].line-numbers-mode .highlight-lines .highlighted:before{background-color:hsla(0,0%,78.4%,.4)}.theme-mode-dark{--bodyBg:#1e1e22;--mainBg:#1e1e22;--sidebarBg:rgba(30,30,34,0.8);--blurBg:rgba(30,30,34,0.8);--textColor:#8c8c96;--textLightenColor:#0085ad;--borderColor:#2c2c3a;--codeBg:#252526;--codeColor:#fff}.theme-mode-dark code[class*=language-],.theme-mode-dark pre[class*=language-]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-dark pre[class*=language-]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-dark :not(pre)>code[class*=language-],.theme-mode-dark pre[class*=language-]{background:#2d2d2d}.theme-mode-dark :not(pre)>code[class*=language-]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-dark .token.block-comment,.theme-mode-dark .token.cdata,.theme-mode-dark .token.comment,.theme-mode-dark .token.doctype,.theme-mode-dark .token.prolog{color:#999}.theme-mode-dark .token.punctuation{color:#ccc}.theme-mode-dark .token.attr-name,.theme-mode-dark .token.deleted,.theme-mode-dark .token.namespace,.theme-mode-dark .token.tag{color:#e2777a}.theme-mode-dark .token.function-name{color:#6196cc}.theme-mode-dark .token.boolean,.theme-mode-dark .token.function,.theme-mode-dark .token.number{color:#f08d49}.theme-mode-dark .token.class-name,.theme-mode-dark .token.constant,.theme-mode-dark .token.property,.theme-mode-dark .token.symbol{color:#f8c555}.theme-mode-dark .token.atrule,.theme-mode-dark .token.builtin,.theme-mode-dark .token.important,.theme-mode-dark .token.keyword,.theme-mode-dark .token.selector{color:#cc99cd}.theme-mode-dark .token.attr-value,.theme-mode-dark .token.char,.theme-mode-dark .token.regex,.theme-mode-dark .token.string,.theme-mode-dark .token.variable{color:#7ec699}.theme-mode-dark .token.entity,.theme-mode-dark .token.operator,.theme-mode-dark .token.url{color:#67cdcc}.theme-mode-dark .language-css .token.string,.theme-mode-dark .style .token.string,.theme-mode-dark .token.entity,.theme-mode-dark .token.operator,.theme-mode-dark .token.url{background:none}.theme-mode-dark .token.bold,.theme-mode-dark .token.important{font-weight:700}.theme-mode-dark .token.italic{font-style:italic}.theme-mode-dark .token.entity{cursor:help}.theme-mode-dark .token.inserted{color:green}.theme-mode-read{--bodyBg:#f5f5d5;--mainBg:#f5f5d5;--sidebarBg:rgba(245,245,213,0.8);--blurBg:rgba(245,245,213,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#282c34;--codeColor:#fff}.theme-mode-read code[class*=language-],.theme-mode-read pre[class*=language-]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-read pre[class*=language-]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-read :not(pre)>code[class*=language-],.theme-mode-read pre[class*=language-]{background:#2d2d2d}.theme-mode-read :not(pre)>code[class*=language-]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-read .token.block-comment,.theme-mode-read .token.cdata,.theme-mode-read .token.comment,.theme-mode-read .token.doctype,.theme-mode-read .token.prolog{color:#999}.theme-mode-read .token.punctuation{color:#ccc}.theme-mode-read .token.attr-name,.theme-mode-read .token.deleted,.theme-mode-read .token.namespace,.theme-mode-read .token.tag{color:#e2777a}.theme-mode-read .token.function-name{color:#6196cc}.theme-mode-read .token.boolean,.theme-mode-read .token.function,.theme-mode-read .token.number{color:#f08d49}.theme-mode-read .token.class-name,.theme-mode-read .token.constant,.theme-mode-read .token.property,.theme-mode-read .token.symbol{color:#f8c555}.theme-mode-read .token.atrule,.theme-mode-read .token.builtin,.theme-mode-read .token.important,.theme-mode-read .token.keyword,.theme-mode-read .token.selector{color:#cc99cd}.theme-mode-read .token.attr-value,.theme-mode-read .token.char,.theme-mode-read .token.regex,.theme-mode-read .token.string,.theme-mode-read .token.variable{color:#7ec699}.theme-mode-read .token.entity,.theme-mode-read .token.operator,.theme-mode-read .token.url{color:#67cdcc}.theme-mode-read .language-css .token.string,.theme-mode-read .style .token.string,.theme-mode-read .token.entity,.theme-mode-read .token.operator,.theme-mode-read .token.url{background:none}.theme-mode-read .token.bold,.theme-mode-read .token.important{font-weight:700}.theme-mode-read .token.italic{font-style:italic}.theme-mode-read .token.entity{cursor:help}.theme-mode-read .token.inserted{color:green}.custom-html-window{position:fixed;bottom:0;display:flex;overflow:hidden;font-weight:350}@media (max-width:960px){.custom-html-window{display:none}}.custom-html-window .custom-wrapper{position:relative;max-width:200px;max-height:400px}.custom-html-window .custom-wrapper .close-but{cursor:pointer;position:absolute;right:0;top:0;font-size:1.5rem;line-height:1.5rem;width:1.5rem;height:1.5rem;opacity:0;transition:all .2s}.custom-html-window .custom-wrapper .close-but:hover{opacity:.9}.custom-html-window .custom-wrapper:hover .close-but{opacity:.7}.custom-html-window.custom-html-window-lb{left:0;z-index:99}.custom-html-window.custom-html-window-lb>*{align-self:flex-end}.custom-html-window.custom-html-window-rb{right:80px;z-index:10;justify-content:flex-end}.custom-html-window.custom-html-window-rb>*{align-self:flex-end}.theme-mode-light[data-v-d5affa18]{--bodyBg:#f4f4f4;--customBlockBg:#f1f1f1;--textColor:#00323c;--borderColor:rgba(0,0,0,0.12)}.theme-mode-dark[data-v-d5affa18]{--bodyBg:#27272b;--customBlockBg:#27272b;--textColor:#9b9baa;--borderColor:#30363d}.theme-mode-read[data-v-d5affa18]{--bodyBg:#ececcc;--customBlockBg:#ececcc;--textColor:#704214;--textLightenColor:#963}.theme-style-line.theme-mode-light[data-v-d5affa18]{--bodyBg:#fff}.theme-style-line.theme-mode-dark[data-v-d5affa18]{--bodyBg:#1e1e22}.theme-style-line.theme-mode-read[data-v-d5affa18]{--bodyBg:#f5f5d5}.theme-mode-light[data-v-d5affa18]{--bodyBg:#fff;--mainBg:#fff;--sidebarBg:hsla(0,0%,100%,0.8);--blurBg:hsla(0,0%,100%,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#f6f6f6;--codeColor:#525252}.theme-mode-light code[class*=language-][data-v-d5affa18],.theme-mode-light pre[class*=language-][data-v-d5affa18]{color:#000;background:none;text-shadow:0 1px #fff;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-light code[class*=language-][data-v-d5affa18]::-moz-selection,.theme-mode-light code[class*=language-][data-v-d5affa18] ::-moz-selection,.theme-mode-light pre[class*=language-][data-v-d5affa18]::-moz-selection,.theme-mode-light pre[class*=language-][data-v-d5affa18] ::-moz-selection{text-shadow:none;background:#b3d4fc}.theme-mode-light code[class*=language-][data-v-d5affa18]::selection,.theme-mode-light code[class*=language-][data-v-d5affa18] ::selection,.theme-mode-light pre[class*=language-][data-v-d5affa18]::selection,.theme-mode-light pre[class*=language-][data-v-d5affa18] ::selection{text-shadow:none;background:#b3d4fc}@media print{.theme-mode-light code[class*=language-][data-v-d5affa18],.theme-mode-light pre[class*=language-][data-v-d5affa18]{text-shadow:none}}.theme-mode-light pre[class*=language-][data-v-d5affa18]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-light :not(pre)>code[class*=language-][data-v-d5affa18],.theme-mode-light pre[class*=language-][data-v-d5affa18]{background:#f5f2f0}.theme-mode-light :not(pre)>code[class*=language-][data-v-d5affa18]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-light .token.cdata[data-v-d5affa18],.theme-mode-light .token.comment[data-v-d5affa18],.theme-mode-light .token.doctype[data-v-d5affa18],.theme-mode-light .token.prolog[data-v-d5affa18]{color:#708090}.theme-mode-light .token.punctuation[data-v-d5affa18]{color:#999}.theme-mode-light .namespace[data-v-d5affa18]{opacity:.7}.theme-mode-light .token.boolean[data-v-d5affa18],.theme-mode-light .token.constant[data-v-d5affa18],.theme-mode-light .token.deleted[data-v-d5affa18],.theme-mode-light .token.number[data-v-d5affa18],.theme-mode-light .token.property[data-v-d5affa18],.theme-mode-light .token.symbol[data-v-d5affa18],.theme-mode-light .token.tag[data-v-d5affa18]{color:#905}.theme-mode-light .token.attr-name[data-v-d5affa18],.theme-mode-light .token.builtin[data-v-d5affa18],.theme-mode-light .token.char[data-v-d5affa18],.theme-mode-light .token.inserted[data-v-d5affa18],.theme-mode-light .token.selector[data-v-d5affa18],.theme-mode-light .token.string[data-v-d5affa18]{color:#690}.theme-mode-light .language-css .token.string[data-v-d5affa18],.theme-mode-light .style .token.string[data-v-d5affa18],.theme-mode-light .token.entity[data-v-d5affa18],.theme-mode-light .token.operator[data-v-d5affa18],.theme-mode-light .token.url[data-v-d5affa18]{color:#9a6e3a;background:hsla(0,0%,100%,.5)}.theme-mode-light .token.atrule[data-v-d5affa18],.theme-mode-light .token.attr-value[data-v-d5affa18],.theme-mode-light .token.keyword[data-v-d5affa18]{color:#07a}.theme-mode-light .token.class-name[data-v-d5affa18],.theme-mode-light .token.function[data-v-d5affa18]{color:#dd4a68}.theme-mode-light .token.important[data-v-d5affa18],.theme-mode-light .token.regex[data-v-d5affa18],.theme-mode-light .token.variable[data-v-d5affa18]{color:#e90}.theme-mode-light .token.bold[data-v-d5affa18],.theme-mode-light .token.important[data-v-d5affa18]{font-weight:700}.theme-mode-light .token.italic[data-v-d5affa18]{font-style:italic}.theme-mode-light .token.entity[data-v-d5affa18]{cursor:help}.theme-mode-light div[class*=language-] .highlight-lines .highlighted[data-v-d5affa18],.theme-mode-light div[class*=language-].line-numbers-mode .highlight-lines .highlighted[data-v-d5affa18]:before{background-color:hsla(0,0%,78.4%,.4)}.theme-mode-dark[data-v-d5affa18]{--bodyBg:#1e1e22;--mainBg:#1e1e22;--sidebarBg:rgba(30,30,34,0.8);--blurBg:rgba(30,30,34,0.8);--textColor:#8c8c96;--textLightenColor:#0085ad;--borderColor:#2c2c3a;--codeBg:#252526;--codeColor:#fff}.theme-mode-dark code[class*=language-][data-v-d5affa18],.theme-mode-dark pre[class*=language-][data-v-d5affa18]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-dark pre[class*=language-][data-v-d5affa18]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-dark :not(pre)>code[class*=language-][data-v-d5affa18],.theme-mode-dark pre[class*=language-][data-v-d5affa18]{background:#2d2d2d}.theme-mode-dark :not(pre)>code[class*=language-][data-v-d5affa18]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-dark .token.block-comment[data-v-d5affa18],.theme-mode-dark .token.cdata[data-v-d5affa18],.theme-mode-dark .token.comment[data-v-d5affa18],.theme-mode-dark .token.doctype[data-v-d5affa18],.theme-mode-dark .token.prolog[data-v-d5affa18]{color:#999}.theme-mode-dark .token.punctuation[data-v-d5affa18]{color:#ccc}.theme-mode-dark .token.attr-name[data-v-d5affa18],.theme-mode-dark .token.deleted[data-v-d5affa18],.theme-mode-dark .token.namespace[data-v-d5affa18],.theme-mode-dark .token.tag[data-v-d5affa18]{color:#e2777a}.theme-mode-dark .token.function-name[data-v-d5affa18]{color:#6196cc}.theme-mode-dark .token.boolean[data-v-d5affa18],.theme-mode-dark .token.function[data-v-d5affa18],.theme-mode-dark .token.number[data-v-d5affa18]{color:#f08d49}.theme-mode-dark .token.class-name[data-v-d5affa18],.theme-mode-dark .token.constant[data-v-d5affa18],.theme-mode-dark .token.property[data-v-d5affa18],.theme-mode-dark .token.symbol[data-v-d5affa18]{color:#f8c555}.theme-mode-dark .token.atrule[data-v-d5affa18],.theme-mode-dark .token.builtin[data-v-d5affa18],.theme-mode-dark .token.important[data-v-d5affa18],.theme-mode-dark .token.keyword[data-v-d5affa18],.theme-mode-dark .token.selector[data-v-d5affa18]{color:#cc99cd}.theme-mode-dark .token.attr-value[data-v-d5affa18],.theme-mode-dark .token.char[data-v-d5affa18],.theme-mode-dark .token.regex[data-v-d5affa18],.theme-mode-dark .token.string[data-v-d5affa18],.theme-mode-dark .token.variable[data-v-d5affa18]{color:#7ec699}.theme-mode-dark .token.entity[data-v-d5affa18],.theme-mode-dark .token.operator[data-v-d5affa18],.theme-mode-dark .token.url[data-v-d5affa18]{color:#67cdcc}.theme-mode-dark .language-css .token.string[data-v-d5affa18],.theme-mode-dark .style .token.string[data-v-d5affa18],.theme-mode-dark .token.entity[data-v-d5affa18],.theme-mode-dark .token.operator[data-v-d5affa18],.theme-mode-dark .token.url[data-v-d5affa18]{background:none}.theme-mode-dark .token.bold[data-v-d5affa18],.theme-mode-dark .token.important[data-v-d5affa18]{font-weight:700}.theme-mode-dark .token.italic[data-v-d5affa18]{font-style:italic}.theme-mode-dark .token.entity[data-v-d5affa18]{cursor:help}.theme-mode-dark .token.inserted[data-v-d5affa18]{color:green}.theme-mode-read[data-v-d5affa18]{--bodyBg:#f5f5d5;--mainBg:#f5f5d5;--sidebarBg:rgba(245,245,213,0.8);--blurBg:rgba(245,245,213,0.9);--textColor:#004050;--textLightenColor:#0085ad;--borderColor:rgba(0,0,0,0.15);--codeBg:#282c34;--codeColor:#fff}.theme-mode-read code[class*=language-][data-v-d5affa18],.theme-mode-read pre[class*=language-][data-v-d5affa18]{color:#ccc;background:none;text-shadow:none;font-family:Consolas,Monaco,Andale Mono,Ubuntu Mono,monospace;font-size:1em;text-align:left;white-space:pre;word-spacing:normal;word-break:normal;word-wrap:normal;line-height:1.5;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-hyphens:none;hyphens:none}.theme-mode-read pre[class*=language-][data-v-d5affa18]{padding:1em;margin:.5em 0;overflow:auto}.theme-mode-read :not(pre)>code[class*=language-][data-v-d5affa18],.theme-mode-read pre[class*=language-][data-v-d5affa18]{background:#2d2d2d}.theme-mode-read :not(pre)>code[class*=language-][data-v-d5affa18]{padding:.1em;border-radius:.3em;white-space:normal}.theme-mode-read .token.block-comment[data-v-d5affa18],.theme-mode-read .token.cdata[data-v-d5affa18],.theme-mode-read .token.comment[data-v-d5affa18],.theme-mode-read .token.doctype[data-v-d5affa18],.theme-mode-read .token.prolog[data-v-d5affa18]{color:#999}.theme-mode-read .token.punctuation[data-v-d5affa18]{color:#ccc}.theme-mode-read .token.attr-name[data-v-d5affa18],.theme-mode-read .token.deleted[data-v-d5affa18],.theme-mode-read .token.namespace[data-v-d5affa18],.theme-mode-read .token.tag[data-v-d5affa18]{color:#e2777a}.theme-mode-read .token.function-name[data-v-d5affa18]{color:#6196cc}.theme-mode-read .token.boolean[data-v-d5affa18],.theme-mode-read .token.function[data-v-d5affa18],.theme-mode-read .token.number[data-v-d5affa18]{color:#f08d49}.theme-mode-read .token.class-name[data-v-d5affa18],.theme-mode-read .token.constant[data-v-d5affa18],.theme-mode-read .token.property[data-v-d5affa18],.theme-mode-read .token.symbol[data-v-d5affa18]{color:#f8c555}.theme-mode-read .token.atrule[data-v-d5affa18],.theme-mode-read .token.builtin[data-v-d5affa18],.theme-mode-read .token.important[data-v-d5affa18],.theme-mode-read .token.keyword[data-v-d5affa18],.theme-mode-read .token.selector[data-v-d5affa18]{color:#cc99cd}.theme-mode-read .token.attr-value[data-v-d5affa18],.theme-mode-read .token.char[data-v-d5affa18],.theme-mode-read .token.regex[data-v-d5affa18],.theme-mode-read .token.string[data-v-d5affa18],.theme-mode-read .token.variable[data-v-d5affa18]{color:#7ec699}.theme-mode-read .token.entity[data-v-d5affa18],.theme-mode-read .token.operator[data-v-d5affa18],.theme-mode-read .token.url[data-v-d5affa18]{color:#67cdcc}.theme-mode-read .language-css .token.string[data-v-d5affa18],.theme-mode-read .style .token.string[data-v-d5affa18],.theme-mode-read .token.entity[data-v-d5affa18],.theme-mode-read .token.operator[data-v-d5affa18],.theme-mode-read .token.url[data-v-d5affa18]{background:none}.theme-mode-read .token.bold[data-v-d5affa18],.theme-mode-read .token.important[data-v-d5affa18]{font-weight:700}.theme-mode-read .token.italic[data-v-d5affa18]{font-style:italic}.theme-mode-read .token.entity[data-v-d5affa18]{cursor:help}.theme-mode-read .token.inserted[data-v-d5affa18]{color:green}.badge[data-v-d5affa18]{display:inline-block;font-size:14px;height:18px;line-height:18px;border-radius:3px;padding:0 6px;color:#fff}.badge.green[data-v-d5affa18],.badge.tip[data-v-d5affa18],.badge[data-v-d5affa18]{background-color:#42b983}.badge.error[data-v-d5affa18]{background-color:#da5961}.badge.warn[data-v-d5affa18],.badge.warning[data-v-d5affa18],.badge.yellow[data-v-d5affa18]{background-color:#e7c000}.badge+.badge[data-v-d5affa18]{margin-left:5px}@font-face{font-family:octicons-link;src:url(data:font/woff;charset=utf-8;base64,d09GRgABAAAAAAZwABAAAAAACFQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEU0lHAAAGaAAAAAgAAAAIAAAAAUdTVUIAAAZcAAAACgAAAAoAAQAAT1MvMgAAAyQAAABJAAAAYFYEU3RjbWFwAAADcAAAAEUAAACAAJThvmN2dCAAAATkAAAABAAAAAQAAAAAZnBnbQAAA7gAAACyAAABCUM+8IhnYXNwAAAGTAAAABAAAAAQABoAI2dseWYAAAFsAAABPAAAAZwcEq9taGVhZAAAAsgAAAA0AAAANgh4a91oaGVhAAADCAAAABoAAAAkCA8DRGhtdHgAAAL8AAAADAAAAAwGAACfbG9jYQAAAsAAAAAIAAAACABiATBtYXhwAAACqAAAABgAAAAgAA8ASm5hbWUAAAToAAABQgAAAlXu73sOcG9zdAAABiwAAAAeAAAAME3QpOBwcmVwAAAEbAAAAHYAAAB/aFGpk3jaTY6xa8JAGMW/O62BDi0tJLYQincXEypYIiGJjSgHniQ6umTsUEyLm5BV6NDBP8Tpts6F0v+k/0an2i+itHDw3v2+9+DBKTzsJNnWJNTgHEy4BgG3EMI9DCEDOGEXzDADU5hBKMIgNPZqoD3SilVaXZCER3/I7AtxEJLtzzuZfI+VVkprxTlXShWKb3TBecG11rwoNlmmn1P2WYcJczl32etSpKnziC7lQyWe1smVPy/Lt7Kc+0vWY/gAgIIEqAN9we0pwKXreiMasxvabDQMM4riO+qxM2ogwDGOZTXxwxDiycQIcoYFBLj5K3EIaSctAq2kTYiw+ymhce7vwM9jSqO8JyVd5RH9gyTt2+J/yUmYlIR0s04n6+7Vm1ozezUeLEaUjhaDSuXHwVRgvLJn1tQ7xiuVv/ocTRF42mNgZGBgYGbwZOBiAAFGJBIMAAizAFoAAABiAGIAznjaY2BkYGAA4in8zwXi+W2+MjCzMIDApSwvXzC97Z4Ig8N/BxYGZgcgl52BCSQKAA3jCV8CAABfAAAAAAQAAEB42mNgZGBg4f3vACQZQABIMjKgAmYAKEgBXgAAeNpjYGY6wTiBgZWBg2kmUxoDA4MPhGZMYzBi1AHygVLYQUCaawqDA4PChxhmh/8ODDEsvAwHgMKMIDnGL0x7gJQCAwMAJd4MFwAAAHjaY2BgYGaA4DAGRgYQkAHyGMF8NgYrIM3JIAGVYYDT+AEjAwuDFpBmA9KMDEwMCh9i/v8H8sH0/4dQc1iAmAkALaUKLgAAAHjaTY9LDsIgEIbtgqHUPpDi3gPoBVyRTmTddOmqTXThEXqrob2gQ1FjwpDvfwCBdmdXC5AVKFu3e5MfNFJ29KTQT48Ob9/lqYwOGZxeUelN2U2R6+cArgtCJpauW7UQBqnFkUsjAY/kOU1cP+DAgvxwn1chZDwUbd6CFimGXwzwF6tPbFIcjEl+vvmM/byA48e6tWrKArm4ZJlCbdsrxksL1AwWn/yBSJKpYbq8AXaaTb8AAHja28jAwOC00ZrBeQNDQOWO//sdBBgYGRiYWYAEELEwMTE4uzo5Zzo5b2BxdnFOcALxNjA6b2ByTswC8jYwg0VlNuoCTWAMqNzMzsoK1rEhNqByEyerg5PMJlYuVueETKcd/89uBpnpvIEVomeHLoMsAAe1Id4AAAAAAAB42oWQT07CQBTGv0JBhagk7HQzKxca2sJCE1hDt4QF+9JOS0nbaaYDCQfwCJ7Au3AHj+LO13FMmm6cl7785vven0kBjHCBhfpYuNa5Ph1c0e2Xu3jEvWG7UdPDLZ4N92nOm+EBXuAbHmIMSRMs+4aUEd4Nd3CHD8NdvOLTsA2GL8M9PODbcL+hD7C1xoaHeLJSEao0FEW14ckxC+TU8TxvsY6X0eLPmRhry2WVioLpkrbp84LLQPGI7c6sOiUzpWIWS5GzlSgUzzLBSikOPFTOXqly7rqx0Z1Q5BAIoZBSFihQYQOOBEdkCOgXTOHA07HAGjGWiIjaPZNW13/+lm6S9FT7rLHFJ6fQbkATOG1j2OFMucKJJsxIVfQORl+9Jyda6Sl1dUYhSCm1dyClfoeDve4qMYdLEbfqHf3O/AdDumsjAAB42mNgYoAAZQYjBmyAGYQZmdhL8zLdDEydARfoAqIAAAABAAMABwAKABMAB///AA8AAQAAAAAAAAAAAAAAAAABAAAAAA==) format("woff")}.markdown-body{-ms-text-size-adjust:100%;-webkit-text-size-adjust:100%;color:#24292e;font-family:-apple-system,BlinkMacSystemFont,Segoe UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol;font-size:16px;line-height:1.5;word-wrap:break-word}.markdown-body .pl-c{color:#6a737d}.markdown-body .pl-c1,.markdown-body .pl-s .pl-v{color:#005cc5}.markdown-body .pl-e,.markdown-body .pl-en{color:#6f42c1}.markdown-body .pl-s .pl-s1,.markdown-body .pl-smi{color:#24292e}.markdown-body .pl-ent{color:#22863a}.markdown-body .pl-k{color:#d73a49}.markdown-body .pl-pds,.markdown-body .pl-s,.markdown-body .pl-s .pl-pse .pl-s1,.markdown-body .pl-sr,.markdown-body .pl-sr .pl-cce,.markdown-body .pl-sr .pl-sra,.markdown-body .pl-sr .pl-sre{color:#032f62}.markdown-body .pl-smw,.markdown-body .pl-v{color:#e36209}.markdown-body .pl-bu{color:#b31d28}.markdown-body .pl-ii{color:#fafbfc;background-color:#b31d28}.markdown-body .pl-c2{color:#fafbfc;background-color:#d73a49}.markdown-body .pl-c2:before{content:"^M"}.markdown-body .pl-sr .pl-cce{font-weight:700;color:#22863a}.markdown-body .pl-ml{color:#735c0f}.markdown-body .pl-mh,.markdown-body .pl-mh .pl-en,.markdown-body .pl-ms{font-weight:700;color:#005cc5}.markdown-body .pl-mi{font-style:italic;color:#24292e}.markdown-body .pl-mb{font-weight:700;color:#24292e}.markdown-body .pl-md{color:#b31d28;background-color:#ffeef0}.markdown-body .pl-mi1{color:#22863a;background-color:#f0fff4}.markdown-body .pl-mc{color:#e36209;background-color:#ffebda}.markdown-body .pl-mi2{color:#f6f8fa;background-color:#005cc5}.markdown-body .pl-mdr{font-weight:700;color:#6f42c1}.markdown-body .pl-ba{color:#586069}.markdown-body .pl-sg{color:#959da5}.markdown-body .pl-corl{text-decoration:underline;color:#032f62}.markdown-body .octicon{display:inline-block;vertical-align:text-top;fill:currentColor}.markdown-body a{background-color:transparent;-webkit-text-decoration-skip:objects}.markdown-body a:active,.markdown-body a:hover{outline-width:0}.markdown-body strong{font-weight:inherit;font-weight:bolder}.markdown-body h1{margin:.67em 0}.markdown-body img{border-style:none}.markdown-body svg:not(:root){overflow:hidden}.markdown-body code,.markdown-body kbd,.markdown-body pre{font-family:monospace,monospace;font-size:1em}.markdown-body hr{box-sizing:content-box;overflow:visible}.markdown-body input{font:inherit;margin:0;overflow:visible}.markdown-body [type=checkbox]{box-sizing:border-box;padding:0}.markdown-body *{box-sizing:border-box}.markdown-body input{font-family:inherit;font-size:inherit;line-height:inherit}.markdown-body a{color:#0366d6;text-decoration:none}.markdown-body a:hover{text-decoration:underline}.markdown-body strong{font-weight:600}.markdown-body hr{height:0;margin:15px 0;overflow:hidden;background:transparent;border-bottom:1px solid #dfe2e5}.markdown-body hr:after,.markdown-body hr:before{display:table;content:""}.markdown-body hr:after{clear:both}.markdown-body table{border-spacing:0;border-collapse:collapse}.markdown-body td,.markdown-body th{padding:0}.markdown-body h1,.markdown-body h2,.markdown-body h3,.markdown-body h4,.markdown-body h5,.markdown-body h6{margin-top:0;margin-bottom:0}.markdown-body h1{font-size:32px;font-weight:600}.markdown-body h2{font-size:24px;font-weight:600}.markdown-body h3{font-size:20px;font-weight:600}.markdown-body h4{font-size:16px;font-weight:600}.markdown-body h5{font-size:14px;font-weight:600}.markdown-body h6{font-size:12px;font-weight:600}.markdown-body p{margin-top:0;margin-bottom:10px}.markdown-body blockquote{margin:0}.markdown-body ol,.markdown-body ul{padding-left:0;margin-top:0;margin-bottom:0}.markdown-body ol ol,.markdown-body ul ol{list-style-type:lower-roman}.markdown-body ol ol ol,.markdown-body ol ul ol,.markdown-body ul ol ol,.markdown-body ul ul ol{list-style-type:lower-alpha}.markdown-body dd{margin-left:0}.markdown-body code{font-family:SFMono-Regular,Consolas,Liberation Mono,Menlo,Courier,monospace;font-size:12px}.markdown-body pre{margin-top:0;margin-bottom:0;font:12px SFMono-Regular,Consolas,Liberation Mono,Menlo,Courier,monospace}.markdown-body .octicon{vertical-align:text-bottom}.markdown-body .pl-0{padding-left:0!important}.markdown-body .pl-1{padding-left:4px!important}.markdown-body .pl-2{padding-left:8px!important}.markdown-body .pl-3{padding-left:16px!important}.markdown-body .pl-4{padding-left:24px!important}.markdown-body .pl-5{padding-left:32px!important}.markdown-body .pl-6{padding-left:40px!important}.markdown-body:after,.markdown-body:before{display:table;content:""}.markdown-body:after{clear:both}.markdown-body>:first-child{margin-top:0!important}.markdown-body>:last-child{margin-bottom:0!important}.markdown-body a:not([href]){color:inherit;text-decoration:none}.markdown-body .anchor{float:left;padding-right:4px;margin-left:-20px;line-height:1}.markdown-body .anchor:focus{outline:none}.markdown-body blockquote,.markdown-body dl,.markdown-body ol,.markdown-body p,.markdown-body pre,.markdown-body table,.markdown-body ul{margin-top:0;margin-bottom:16px}.markdown-body hr{height:.25em;padding:0;margin:24px 0;background-color:#e1e4e8;border:0}.markdown-body blockquote{padding:0 1em;color:#6a737d;border-left:.25em solid #dfe2e5}.markdown-body blockquote>:first-child{margin-top:0}.markdown-body blockquote>:last-child{margin-bottom:0}.markdown-body kbd{font-size:11px;border:1px solid #c6cbd1;border-bottom-color:#959da5;box-shadow:inset 0 -1px 0 #959da5}.markdown-body h1,.markdown-body h2,.markdown-body h3,.markdown-body h4,.markdown-body h5,.markdown-body h6{margin-top:24px;margin-bottom:16px;font-weight:600;line-height:1.25}.markdown-body h1 .octicon-link,.markdown-body h2 .octicon-link,.markdown-body h3 .octicon-link,.markdown-body h4 .octicon-link,.markdown-body h5 .octicon-link,.markdown-body h6 .octicon-link{color:#1b1f23;vertical-align:middle;visibility:hidden}.markdown-body h1:hover .anchor,.markdown-body h2:hover .anchor,.markdown-body h3:hover .anchor,.markdown-body h4:hover .anchor,.markdown-body h5:hover .anchor,.markdown-body h6:hover .anchor{text-decoration:none}.markdown-body h1:hover .anchor .octicon-link,.markdown-body h2:hover .anchor .octicon-link,.markdown-body h3:hover .anchor .octicon-link,.markdown-body h4:hover .anchor .octicon-link,.markdown-body h5:hover .anchor .octicon-link,.markdown-body h6:hover .anchor .octicon-link{visibility:visible}.markdown-body h1{font-size:2em}.markdown-body h1,.markdown-body h2{padding-bottom:.3em;border-bottom:1px solid #eaecef}.markdown-body h2{font-size:1.5em}.markdown-body h3{font-size:1.25em}.markdown-body h4{font-size:1em}.markdown-body h5{font-size:.875em}.markdown-body h6{font-size:.85em;color:#6a737d}.markdown-body ol,.markdown-body ul{padding-left:2em}.markdown-body ol ol,.markdown-body ol ul,.markdown-body ul ol,.markdown-body ul ul{margin-top:0;margin-bottom:0}.markdown-body li>p{margin-top:16px}.markdown-body li+li{margin-top:.25em}.markdown-body dl{padding:0}.markdown-body dl dt{padding:0;margin-top:16px;font-size:1em;font-style:italic;font-weight:600}.markdown-body dl dd{padding:0 16px;margin-bottom:16px}.markdown-body table{display:block;width:100%;overflow:auto}.markdown-body table th{font-weight:600}.markdown-body table td,.markdown-body table th{padding:6px 13px;border:1px solid #dfe2e5}.markdown-body table tr{background-color:#fff;border-top:1px solid #c6cbd1}.markdown-body table tr:nth-child(2n){background-color:#f6f8fa}.markdown-body img{max-width:100%;box-sizing:content-box;background-color:#fff}.markdown-body code{padding:.2em 0;margin:0;font-size:85%;background-color:rgba(27,31,35,.05);border-radius:3px}.markdown-body code:after,.markdown-body code:before{letter-spacing:-.2em;content:"\A0"}.markdown-body pre{word-wrap:normal}.markdown-body pre>code{padding:0;margin:0;font-size:100%;word-break:normal;white-space:pre;background:transparent;border:0}.markdown-body .highlight{margin-bottom:16px}.markdown-body .highlight pre{margin-bottom:0;word-break:normal}.markdown-body .highlight pre,.markdown-body pre{padding:16px;overflow:auto;font-size:85%;line-height:1.45;background-color:#f6f8fa;border-radius:3px}.markdown-body pre code{display:inline;max-width:auto;padding:0;margin:0;overflow:visible;line-height:inherit;word-wrap:normal;background-color:transparent;border:0}.markdown-body pre code:after,.markdown-body pre code:before{content:normal}.markdown-body .full-commit .btn-outline:not(:disabled):hover{color:#005cc5;border-color:#005cc5}.markdown-body kbd{display:inline-block;padding:3px 5px;font:11px SFMono-Regular,Consolas,Liberation Mono,Menlo,Courier,monospace;line-height:10px;color:#444d56;vertical-align:middle;background-color:#fafbfc;border:1px solid #d1d5da;border-bottom-color:#c6cbd1;border-radius:3px;box-shadow:inset 0 -1px 0 #c6cbd1}.markdown-body :checked+.radio-label{position:relative;z-index:1;border-color:#0366d6}.markdown-body .task-list-item{list-style-type:none}.markdown-body .task-list-item+.task-list-item{margin-top:3px}.markdown-body .task-list-item input{margin:0 .2em .25em -1.6em;vertical-align:middle}.markdown-body hr{border-bottom-color:#eee}.gt-container{font-size:16px}.gt-container,.gt-container *{box-sizing:border-box}.gt-container a{color:#6190e8}.gt-container a:hover{color:#81a6ed;border-color:#81a6ed}.gt-container a.is--active{color:#333;cursor:default!important}.gt-container a.is--active:hover{color:#333}.gt-container .hide{display:none!important}.gt-container .gt-svg{display:inline-block;width:1em;height:1em;vertical-align:sub}.gt-container .gt-svg svg{width:100%;height:100%;fill:#6190e8}.gt-container .gt-ico{display:inline-block}.gt-container .gt-ico-text{margin-left:.3125em}.gt-container .gt-ico-github,.gt-container .gt-ico-github .gt-svg{width:100%;height:100%}.gt-container .gt-ico-github svg{fill:inherit}.gt-container .gt-spinner{position:relative}.gt-container .gt-spinner:before{content:"";box-sizing:border-box;position:absolute;top:3px;width:.75em;height:.75em;margin-top:-.1875em;margin-left:-.375em;border-radius:50%;border:1px solid #fff;border-top-color:#6190e8;animation:gt-kf-rotate .6s linear infinite}.gt-container .gt-loader{position:relative;border:1px solid #999;animation:gt-kf-rotate 1.5s ease infinite;display:inline-block;font-style:normal;width:1.75em;height:1.75em;line-height:1.75em;border-radius:50%}.gt-container .gt-loader:before{content:"";position:absolute;display:block;top:0;left:50%;margin-top:-.1875em;margin-left:-.1875em;width:.375em;height:.375em;background-color:#999;border-radius:50%}.gt-container .gt-avatar{display:inline-block;width:3.125em;height:3.125em}@media (max-width:479px){.gt-container .gt-avatar{width:2em;height:2em}}.gt-container .gt-avatar img{width:100%;height:auto;border-radius:3px}.gt-container .gt-avatar-github{width:3em;height:3em;cursor:pointer}@media (max-width:479px){.gt-container .gt-avatar-github{width:1.875em;height:1.875em}}.gt-container .gt-btn{padding:.75em 1.25em;display:inline-block;line-height:1;text-decoration:none;white-space:nowrap;cursor:pointer;border:1px solid #6190e8;border-radius:5px;background-color:#6190e8;color:#fff;outline:none;font-size:.75em}.gt-container .gt-btn-text{font-weight:400}.gt-container .gt-btn-loading{position:relative;margin-left:.5em;display:inline-block;width:.75em;height:1em;vertical-align:top}.gt-container .gt-btn.is--disable{cursor:not-allowed;opacity:.5}.gt-container .gt-btn-login{margin-right:0}.gt-container .gt-btn-preview{background-color:#fff;color:#6190e8}.gt-container .gt-btn-preview:hover{background-color:#f2f2f2;border-color:#81a6ed}.gt-container .gt-btn-public:hover{background-color:#81a6ed;border-color:#81a6ed}.gt-container .gt-error{text-align:center;margin:.625em;color:#ff3860}.gt-container .gt-initing{padding:1.25em 0;text-align:center}.gt-container .gt-initing-text{margin:.625em auto;font-size:92%}.gt-container .gt-no-init{padding:1.25em 0;text-align:center}.gt-container .gt-link{border-bottom:1px dotted #6190e8}.gt-container .gt-link-counts,.gt-container .gt-link-project{text-decoration:none}.gt-container .gt-meta{margin:1.25em 0;padding:1em 0;border-bottom:1px solid #e9e9e9;font-size:1em;position:relative;z-index:10}.gt-container .gt-meta:after,.gt-container .gt-meta:before{content:" ";display:table}.gt-container .gt-meta:after{clear:both}.gt-container .gt-counts{margin:0 .625em 0 0}.gt-container .gt-user{float:right;margin:0;font-size:92%}.gt-container .gt-user-pic{width:16px;height:16px;vertical-align:top;margin-right:.5em}.gt-container .gt-user-inner{display:inline-block;cursor:pointer}.gt-container .gt-user .gt-ico{margin:0 0 0 .3125em}.gt-container .gt-user .gt-ico svg{fill:inherit}.gt-container .gt-user .is--poping .gt-ico svg{fill:#6190e8}.gt-container .gt-version{color:#a1a1a1;margin-left:.375em}.gt-container .gt-copyright{margin:0 .9375em .5em;border-top:1px solid #e9e9e9;padding-top:.5em}.gt-container .gt-popup{position:absolute;right:0;top:2.375em;background:#fff;display:inline-block;border:1px solid #e9e9e9;padding:.625em 0;font-size:.875em;letter-spacing:.5px}.gt-container .gt-popup .gt-action{cursor:pointer;display:block;margin:.5em 0;padding:0 1.125em;position:relative;text-decoration:none}.gt-container .gt-popup .gt-action.is--active:before{content:"";width:.25em;height:.25em;background:#6190e8;position:absolute;left:.5em;top:.4375em}.gt-container .gt-header{position:relative;display:flex}.gt-container .gt-header-comment{flex:1;margin-left:1.25em}@media (max-width:479px){.gt-container .gt-header-comment{margin-left:.875em}}.gt-container .gt-header-textarea{padding:.75em;display:block;box-sizing:border-box;width:100%;min-height:5.125em;max-height:15em;border-radius:5px;border:1px solid rgba(0,0,0,.1);font-size:.875em;word-wrap:break-word;resize:vertical;background-color:#f6f6f6;outline:none;transition:all .25s ease}.gt-container .gt-header-textarea:hover{background-color:#fbfbfb}.gt-container .gt-header-preview{padding:.75em;border-radius:5px;border:1px solid rgba(0,0,0,.1);background-color:#f6f6f6}.gt-container .gt-header-controls{position:relative;margin:.75em 0 0}.gt-container .gt-header-controls:after,.gt-container .gt-header-controls:before{content:" ";display:table}.gt-container .gt-header-controls:after{clear:both}@media (max-width:479px){.gt-container .gt-header-controls{margin:0}}.gt-container .gt-header-controls-tip{font-size:.875em;color:#6190e8;text-decoration:none;vertical-align:sub}@media (max-width:479px){.gt-container .gt-header-controls-tip{display:none}}.gt-container .gt-header-controls .gt-btn{float:right;margin-left:1.25em}@media (max-width:479px){.gt-container .gt-header-controls .gt-btn{float:none;width:100%;margin:.75em 0 0}}.gt-container:after{content:"";position:fixed;bottom:100%;left:0;right:0;top:0;opacity:0}.gt-container.gt-input-focused{position:relative}.gt-container.gt-input-focused:after{content:"";position:fixed;bottom:0;left:0;right:0;top:0;background:#000;opacity:.6;transition:opacity .3s,bottom 0s;z-index:9999}.gt-container.gt-input-focused .gt-header-comment{z-index:10000}.gt-container .gt-comments{padding-top:1.25em}.gt-container .gt-comments-null{text-align:center}.gt-container .gt-comments-controls{margin:1.25em 0;text-align:center}.gt-container .gt-comment{position:relative;padding:.625em 0;display:flex}.gt-container .gt-comment-content{flex:1;margin-left:1.25em;padding:.75em 1em;background-color:#f9f9f9;overflow:auto;transition:all .25s ease}.gt-container .gt-comment-content:hover{box-shadow:0 .625em 3.75em 0 #f4f4f4}@media (max-width:479px){.gt-container .gt-comment-content{margin-left:.875em;padding:.625em .75em}}.gt-container .gt-comment-header{margin-bottom:.5em;font-size:.875em;position:relative}.gt-container .gt-comment-block-1{float:right;height:1.375em;width:2em}.gt-container .gt-comment-block-2{float:right;height:1.375em;width:4em}.gt-container .gt-comment-username{font-weight:500;color:#6190e8;text-decoration:none}.gt-container .gt-comment-username:hover{text-decoration:underline}.gt-container .gt-comment-date,.gt-container .gt-comment-text{margin-left:.5em;color:#a1a1a1}.gt-container .gt-comment-edit,.gt-container .gt-comment-like,.gt-container .gt-comment-reply{position:absolute;height:1.375em}.gt-container .gt-comment-edit:hover,.gt-container .gt-comment-like:hover,.gt-container .gt-comment-reply:hover{cursor:pointer}.gt-container .gt-comment-like{top:0;right:2em}.gt-container .gt-comment-edit,.gt-container .gt-comment-reply{top:0;right:0}.gt-container .gt-comment-body{color:#333!important}.gt-container .gt-comment-body .email-hidden-toggle a{display:inline-block;height:12px;padding:0 9px;font-size:12px;font-weight:600;line-height:6px;color:#444d56;text-decoration:none;vertical-align:middle;background:#dfe2e5;border-radius:1px}.gt-container .gt-comment-body .email-hidden-toggle a:hover{background-color:#c6cbd1}.gt-container .gt-comment-body .email-hidden-reply{display:none;white-space:pre-wrap}.gt-container .gt-comment-body .email-hidden-reply .email-signature-reply{padding:0 15px;margin:15px 0;color:#586069;border-left:4px solid #dfe2e5}.gt-container .gt-comment-body .email-hidden-reply.expanded{display:block}.gt-container .gt-comment-admin .gt-comment-content{background-color:#f6f9fe}@keyframes gt-kf-rotate{0%{transform:rotate(0)}to{transform:rotate(1turn)}} \ No newline at end of file diff --git a/assets/img/search.237d6f6a.svg b/assets/img/search.237d6f6a.svg new file mode 100644 index 00000000..18ed22ab --- /dev/null +++ b/assets/img/search.237d6f6a.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/assets/js/10.1ecb1548.js b/assets/js/10.1ecb1548.js new file mode 100644 index 00000000..8b0b9492 --- /dev/null +++ b/assets/js/10.1ecb1548.js @@ -0,0 +1 @@ +(window.webpackJsonp=window.webpackJsonp||[]).push([[10],{347:function(a,t,s){"use strict";s.r(t);var n=s(4),e=Object(n.a)({},(function(){var a=this,t=a._self._c;return t("ContentSlotsDistributor",{attrs:{"slot-key":a.$parent.slotKey}},[t("h1",{attrs:{id:"版本管理中间件-flyway"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#版本管理中间件-flyway"}},[a._v("#")]),a._v(" 版本管理中间件 Flyway")]),a._v(" "),t("blockquote",[t("p",[a._v("Flyway 是一个数据迁移工具。")])]),a._v(" "),t("h2",{attrs:{id:"简介"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#简介"}},[a._v("#")]),a._v(" 简介")]),a._v(" "),t("h3",{attrs:{id:"什么是-flyway"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#什么是-flyway"}},[a._v("#")]),a._v(" 什么是 Flyway")]),a._v(" "),t("p",[t("strong",[a._v("Flyway 是一个开源的数据库迁移工具。")])]),a._v(" "),t("h3",{attrs:{id:"为什么要使用数据迁移"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#为什么要使用数据迁移"}},[a._v("#")]),a._v(" 为什么要使用数据迁移")]),a._v(" "),t("p",[a._v("为了说明数据迁移的作用，我们来举一个示例：")]),a._v(" "),t("p",[a._v("（1）假设，有一个叫做 Shiny 的项目，它的架构是一个叫做 Shiny Soft 的 App 连接叫做 Shiny DB 的数据库。")]),a._v(" "),t("p",[a._v("（2）对于大多数项目而言，最简单的持续集成场景如下所示：")]),a._v(" "),t("p",[t("img",{attrs:{src:"https://flywaydb.org/assets/balsamiq/Environments.png",alt:"img"}})]),a._v(" "),t("p",[a._v("这意味着，我们不仅仅要处理一份环境中的修改，由此会引入一些版本冲突问题：")]),a._v(" "),t("p",[a._v("在代码侧（即应用软件）的版本问题比较容易解决：")]),a._v(" "),t("ul",[t("li",[a._v("有方便的版本控制工具")]),a._v(" "),t("li",[a._v("有可复用的构建和持续集成")]),a._v(" "),t("li",[a._v("规范的发布和部署过程")])]),a._v(" "),t("p",[a._v("那么，数据库层面的版本问题如何解决呢？")]),a._v(" "),t("p",[a._v("目前仍然没有方便的数据库版本工具。许多项目仍使用 sql 脚本来解决版本冲突，甚至是遇到冲突问题时才想起用 sql 语句去解决。")]),a._v(" "),t("p",[a._v("由此，引发一些问题：")]),a._v(" "),t("ul",[t("li",[a._v("机器上的数据库是什么状态？")]),a._v(" "),t("li",[a._v("脚本到底生效没有？")]),a._v(" "),t("li",[a._v("生产环境修复的问题是否也在测试环境修复了？")]),a._v(" "),t("li",[a._v("如何建立一个新的数据库实例？")])]),a._v(" "),t("p",[a._v("数据迁移就是用来搞定这些混乱的问题：")]),a._v(" "),t("ul",[t("li",[a._v("通过草稿重建一个数据库。")]),a._v(" "),t("li",[a._v("在任何时候都可以清楚的了解数据库的状态。")]),a._v(" "),t("li",[a._v("以一种明确的方式将数据库从当前版本迁移到一个新版本。")])]),a._v(" "),t("h3",{attrs:{id:"flyway-如何工作"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#flyway-如何工作"}},[a._v("#")]),a._v(" Flyway 如何工作？")]),a._v(" "),t("p",[a._v("最简单的场景是指定 Flyway 迁移到一个空的数据库。")]),a._v(" "),t("p",[t("img",{attrs:{src:"http://upload-images.jianshu.io/upload_images/3101171-bb6e9f39e56ebbda.png",alt:"img"}})]),a._v(" "),t("p",[a._v("Flyway 会尝试查找它的 schema 历史表，如果数据库是空的，Flyway 就不再查找，而是直接创建数据库。")]),a._v(" "),t("p",[a._v("现再你就有了一个仅包含一张空表的数据库，默认情况下，这张表叫 "),t("strong",[a._v("flyway_schema_history")]),a._v("。")]),a._v(" "),t("p",[t("img",{attrs:{src:"http://upload-images.jianshu.io/upload_images/3101171-410eb31c6313b389.png",alt:"img"}})]),a._v(" "),t("p",[a._v("这张表将被用于追踪数据库的状态。")]),a._v(" "),t("p",[a._v("然后，Flyway 将开始扫描文件系统或应用 classpath 中的 "),t("strong",[a._v("migrations")]),a._v("。这些 "),t("strong",[a._v("migrations")]),a._v(" 可以是 sql 或 java。")]),a._v(" "),t("p",[a._v("这些 "),t("strong",[a._v("migrations")]),a._v(" 将根据他们的版本号进行排序。")]),a._v(" "),t("p",[t("img",{attrs:{src:"http://upload-images.jianshu.io/upload_images/3101171-d36ee07ada4efbcd.png",alt:"img"}})]),a._v(" "),t("p",[a._v("任意 migration 应用后，schema 历史表将更新。当元数据和初始状态替换后，可以称之为：迁移到新版本。")]),a._v(" "),t("p",[a._v("Flyway 一旦扫描了文件系统或应用 classpath 下的 migrations，这些 migrations 会检查 schema 历史表。如果它们的版本号低于或等于当前的版本，将被忽略。保留下来的 migrations 是等待的 migrations，有效但没有应用。")]),a._v(" "),t("p",[t("img",{attrs:{src:"http://upload-images.jianshu.io/upload_images/3101171-99a88fea7a31a070.png",alt:"img"}})]),a._v(" "),t("p",[a._v("migrations 将根据版本号排序并按序执行。")]),a._v(" "),t("p",[t("img",{attrs:{src:"http://upload-images.jianshu.io/upload_images/3101171-b444fef6e5c13b71.png",alt:"img"}})]),a._v(" "),t("h2",{attrs:{id:"快速上手"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#快速上手"}},[a._v("#")]),a._v(" 快速上手")]),a._v(" "),t("p",[a._v("Flyway 有 4 种使用方式：")]),a._v(" "),t("ul",[t("li",[a._v("命令行")]),a._v(" "),t("li",[a._v("JAVA API")]),a._v(" "),t("li",[a._v("Maven")]),a._v(" "),t("li",[a._v("Gradle")])]),a._v(" "),t("h3",{attrs:{id:"命令行"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#命令行"}},[a._v("#")]),a._v(" 命令行")]),a._v(" "),t("p",[a._v("适用于非 Java 用户，无需构建。")]),a._v(" "),t("div",{staticClass:"language-shell extra-class"},[t("pre",{pre:!0,attrs:{class:"language-shell"}},[t("code",[t("span",{pre:!0,attrs:{class:"token operator"}},[a._v(">")]),a._v(" flyway migrate "),t("span",{pre:!0,attrs:{class:"token parameter variable"}},[a._v("-url")]),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("=")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("..")]),a._v(". "),t("span",{pre:!0,attrs:{class:"token parameter variable"}},[a._v("-user")]),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("=")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("..")]),a._v(". "),t("span",{pre:!0,attrs:{class:"token parameter variable"}},[a._v("-password")]),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("=")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("..")]),a._v(".\n")])])]),t("p",[a._v("（1）"),t("strong",[a._v("下载解压")])]),a._v(" "),t("p",[a._v("进入"),t("a",{attrs:{href:"https://flywaydb.org/download/",target:"_blank",rel:"noopener noreferrer"}},[a._v("官方下载页面"),t("OutboundLink")],1),a._v("，选择合适版本，下载并解压到本地。")]),a._v(" "),t("p",[a._v("（2）"),t("strong",[a._v("配置 flyway")])]),a._v(" "),t("p",[a._v("编辑 "),t("code",[a._v("/conf/flyway.conf")]),a._v("：")]),a._v(" "),t("div",{staticClass:"language-properties extra-class"},[t("pre",{pre:!0,attrs:{class:"language-properties"}},[t("code",[t("span",{pre:!0,attrs:{class:"token key attr-name"}},[a._v("flyway.url")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("=")]),t("span",{pre:!0,attrs:{class:"token value attr-value"}},[a._v("jdbc:h2:file:./foobardb")]),a._v("\n"),t("span",{pre:!0,attrs:{class:"token key attr-name"}},[a._v("flyway.user")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("=")]),t("span",{pre:!0,attrs:{class:"token value attr-value"}},[a._v("SA")]),a._v("\n"),t("span",{pre:!0,attrs:{class:"token key attr-name"}},[a._v("flyway.password")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("=")]),a._v("\n")])])]),t("p",[a._v("（3）"),t("strong",[a._v("创建第一个 migration")])]),a._v(" "),t("p",[a._v("在 "),t("code",[a._v("/sql")]),a._v(" 目录下创建 "),t("code",[a._v("V1__Create_person_table.sql")]),a._v(" 文件，内容如下：")]),a._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("create")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("table")]),a._v(" PERSON "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),a._v("\n ID "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("int")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("not")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[a._v("null")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v("\n NAME "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("varchar")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[a._v("100")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("not")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[a._v("null")]),a._v("\n"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n")])])]),t("p",[a._v("（4）"),t("strong",[a._v("迁移数据库")])]),a._v(" "),t("p",[a._v("运行 Flyway 来迁移数据库：")]),a._v(" "),t("div",{staticClass:"language-shell extra-class"},[t("pre",{pre:!0,attrs:{class:"language-shell"}},[t("code",[a._v("flyway-5.1."),t("span",{pre:!0,attrs:{class:"token operator"}},[t("span",{pre:!0,attrs:{class:"token file-descriptor important"}},[a._v("4")]),a._v(">")]),a._v(" flyway migrate\n")])])]),t("p",[a._v("运行正常的情况下，应该可以看到如下结果：")]),a._v(" "),t("div",{staticClass:"language- extra-class"},[t("pre",{pre:!0,attrs:{class:"language-text"}},[t("code",[a._v('Database: jdbc:h2:file:./foobardb (H2 1.4)\nSuccessfully validated 1 migration (execution time 00:00.008s)\nCreating Schema History table: "PUBLIC"."flyway_schema_history"\nCurrent version of schema "PUBLIC": << Empty Schema >>\nMigrating schema "PUBLIC" to version 1 - Create person table\nSuccessfully applied 1 migration to schema "PUBLIC" (execution time 00:00.033s)\n')])])]),t("p",[a._v("（5）"),t("strong",[a._v("添加第二个 migration")])]),a._v(" "),t("p",[a._v("在 "),t("code",[a._v("/sql")]),a._v(" 目录下创建 "),t("code",[a._v("V2__Add_people.sql")]),a._v(" 文件，内容如下：")]),a._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("insert")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("into")]),a._v(" PERSON "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),a._v("ID"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" NAME"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("values")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[a._v("1")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[a._v("'Axel'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("insert")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("into")]),a._v(" PERSON "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),a._v("ID"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" NAME"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("values")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[a._v("2")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[a._v("'Mr. Foo'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("insert")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("into")]),a._v(" PERSON "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),a._v("ID"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" NAME"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("values")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[a._v("3")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[a._v("'Ms. Bar'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n")])])]),t("p",[a._v("运行 Flyway")]),a._v(" "),t("div",{staticClass:"language-shell extra-class"},[t("pre",{pre:!0,attrs:{class:"language-shell"}},[t("code",[a._v("flyway-5.1."),t("span",{pre:!0,attrs:{class:"token operator"}},[t("span",{pre:!0,attrs:{class:"token file-descriptor important"}},[a._v("4")]),a._v(">")]),a._v(" flyway migrate\n")])])]),t("p",[a._v("运行正常的情况下，应该可以看到如下结果：")]),a._v(" "),t("div",{staticClass:"language- extra-class"},[t("pre",{pre:!0,attrs:{class:"language-text"}},[t("code",[a._v('Database: jdbc:h2:file:./foobardb (H2 1.4)\nSuccessfully validated 2 migrations (execution time 00:00.018s)\nCurrent version of schema "PUBLIC": 1\nMigrating schema "PUBLIC" to version 2 - Add people\nSuccessfully applied 1 migration to schema "PUBLIC" (execution time 00:00.016s)\n')])])]),t("h3",{attrs:{id:"java-api"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#java-api"}},[a._v("#")]),a._v(" JAVA API")]),a._v(" "),t("p",[a._v("（1）"),t("strong",[a._v("准备")])]),a._v(" "),t("ul",[t("li",[a._v("Java8+")]),a._v(" "),t("li",[a._v("Maven 3.x")])]),a._v(" "),t("p",[a._v("（2）"),t("strong",[a._v("添加依赖")])]),a._v(" "),t("p",[a._v("在 "),t("code",[a._v("pom.xml")]),a._v(" 中添加依赖：")]),a._v(" "),t("div",{staticClass:"language-xml extra-class"},[t("pre",{pre:!0,attrs:{class:"language-xml"}},[t("code",[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("project")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token attr-name"}},[a._v("...")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("\n ...\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("dependencies")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("dependency")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("groupId")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("org.flywaydb"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("artifactId")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("flyway-core"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("version")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("5.1.4"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("dependency")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("groupId")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("com.h2database"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("artifactId")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("h2"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("version")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("1.3.170"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n ...\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n ...\n"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n")])])]),t("p",[a._v("（3）"),t("strong",[a._v("集成 Flyway")])]),a._v(" "),t("p",[a._v("添加 "),t("code",[a._v("App.java")]),a._v(" 文件，内容如下：")]),a._v(" "),t("div",{staticClass:"language-java extra-class"},[t("pre",{pre:!0,attrs:{class:"language-java"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("import")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token import"}},[t("span",{pre:!0,attrs:{class:"token namespace"}},[a._v("org"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(".")]),a._v("flywaydb"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(".")]),a._v("core"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(".")])]),t("span",{pre:!0,attrs:{class:"token class-name"}},[a._v("Flyway")])]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("public")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("class")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token class-name"}},[a._v("App")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("{")]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("public")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("static")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("void")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token function"}},[a._v("main")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token class-name"}},[a._v("String")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("[")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("]")]),a._v(" args"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("{")]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token comment"}},[a._v("// Create the Flyway instance")]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token class-name"}},[a._v("Flyway")]),a._v(" flyway "),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("=")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("new")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token class-name"}},[a._v("Flyway")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n\n "),t("span",{pre:!0,attrs:{class:"token comment"}},[a._v("// Point it to the database")]),a._v("\n flyway"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(".")]),t("span",{pre:!0,attrs:{class:"token function"}},[a._v("setDataSource")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token string"}},[a._v('"jdbc:h2:file:./target/foobar"')]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[a._v('"sa"')]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("null")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n\n "),t("span",{pre:!0,attrs:{class:"token comment"}},[a._v("// Start the migration")]),a._v("\n flyway"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(".")]),t("span",{pre:!0,attrs:{class:"token function"}},[a._v("migrate")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("}")]),a._v("\n"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("}")]),a._v("\n")])])]),t("p",[a._v("（4）"),t("strong",[a._v("创建第一个 migration")])]),a._v(" "),t("p",[a._v("添加 "),t("code",[a._v("src/main/resources/db/migration/V1__Create_person_table.sql")]),a._v(" 文件，内容如下：")]),a._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("create")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("table")]),a._v(" PERSON "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),a._v("\n ID "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("int")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("not")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[a._v("null")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v("\n NAME "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("varchar")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[a._v("100")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("not")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[a._v("null")]),a._v("\n"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n")])])]),t("p",[a._v("（5）"),t("strong",[a._v("执行程序")])]),a._v(" "),t("p",[a._v("执行 "),t("code",[a._v("App#main")]),a._v("：")]),a._v(" "),t("p",[a._v("运行正常的情况下，应该可以看到如下结果：")]),a._v(" "),t("div",{staticClass:"language- extra-class"},[t("pre",{pre:!0,attrs:{class:"language-text"}},[t("code",[a._v('INFO: Creating schema history table: "PUBLIC"."flyway_schema_history"\nINFO: Current version of schema "PUBLIC": << Empty Schema >>\nINFO: Migrating schema "PUBLIC" to version 1 - Create person table\nINFO: Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.062s).\n')])])]),t("p",[a._v("（6）"),t("strong",[a._v("添加第二个 migration")])]),a._v(" "),t("p",[a._v("添加 src/main/resources/db/migration/V2__Add_people.sql 文件，内容如下：")]),a._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("insert")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("into")]),a._v(" PERSON "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),a._v("ID"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" NAME"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("values")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[a._v("1")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[a._v("'Axel'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("insert")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("into")]),a._v(" PERSON "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),a._v("ID"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" NAME"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("values")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[a._v("2")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[a._v("'Mr. Foo'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("insert")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("into")]),a._v(" PERSON "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),a._v("ID"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" NAME"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("values")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[a._v("3")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[a._v("'Ms. Bar'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n")])])]),t("p",[a._v("运行正常的情况下，应该可以看到如下结果：")]),a._v(" "),t("div",{staticClass:"language- extra-class"},[t("pre",{pre:!0,attrs:{class:"language-text"}},[t("code",[a._v('INFO: Current version of schema "PUBLIC": 1\nINFO: Migrating schema "PUBLIC" to version 2 - Add people\nINFO: Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.090s).\n')])])]),t("h3",{attrs:{id:"maven"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#maven"}},[a._v("#")]),a._v(" Maven")]),a._v(" "),t("p",[a._v("与 Java API 方式大体相同，区别在 "),t("strong",[a._v("集成 Flyway")]),a._v(" 步骤：")]),a._v(" "),t("p",[a._v("Maven 方式使用插件来集成 Flyway：")]),a._v(" "),t("div",{staticClass:"language-xml extra-class"},[t("pre",{pre:!0,attrs:{class:"language-xml"}},[t("code",[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("project")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token attr-name"}},[a._v("xmlns")]),t("span",{pre:!0,attrs:{class:"token attr-value"}},[t("span",{pre:!0,attrs:{class:"token punctuation attr-equals"}},[a._v("=")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v('"')]),a._v("..."),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v('"')])]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("\n ...\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("build")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("plugins")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("plugin")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("groupId")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("org.flywaydb"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("artifactId")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("flyway-maven-plugin"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("version")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("5.1.4"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("configuration")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("url")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("jdbc:h2:file:./target/foobar"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("user")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("sa"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("dependencies")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("dependency")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("groupId")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("com.h2database"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("artifactId")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("h2"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("<")]),a._v("version")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(">")])]),a._v("1.4.191"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n"),t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token tag"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("")])]),a._v("\n")])])]),t("p",[a._v("因为用的是插件，所以执行方式不再是运行 Java 类，而是执行 maven 插件：")]),a._v(" "),t("div",{staticClass:"language-shell extra-class"},[t("pre",{pre:!0,attrs:{class:"language-shell"}},[t("code",[t("span",{pre:!0,attrs:{class:"token operator"}},[a._v(">")]),a._v(" mvn flyway:migrate\n")])])]),t("blockquote",[t("p",[a._v("👉 参考："),t("a",{attrs:{href:"https://github.com/dunwu/Database/tree/master/codes/middleware/flyway",target:"_blank",rel:"noopener noreferrer"}},[a._v("示例源码"),t("OutboundLink")],1)])]),a._v(" "),t("h3",{attrs:{id:"gradle"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#gradle"}},[a._v("#")]),a._v(" Gradle")]),a._v(" "),t("p",[a._v("本人不用 Gradle，略。")]),a._v(" "),t("h2",{attrs:{id:"入门篇"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#入门篇"}},[a._v("#")]),a._v(" 入门篇")]),a._v(" "),t("h3",{attrs:{id:"概念"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#概念"}},[a._v("#")]),a._v(" 概念")]),a._v(" "),t("h4",{attrs:{id:"migrations"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#migrations"}},[a._v("#")]),a._v(" Migrations")]),a._v(" "),t("p",[a._v("在 Flyway 中，对于数据库的任何改变都称之为 "),t("strong",[a._v("Migrations")]),a._v("。")]),a._v(" "),t("p",[a._v("Migrations 可以分为 Versioned migrations 和 Repeatable migrations。")]),a._v(" "),t("p",[a._v("Versioned migrations 有 2 种形式：regular 和 undo。")]),a._v(" "),t("p",[a._v("Versioned migrations 和 Repeatable migrations 都可以使用 SQL 或 JAVA 来编写。")]),a._v(" "),t("h5",{attrs:{id:"versioned-migrations"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#versioned-migrations"}},[a._v("#")]),a._v(" Versioned migrations")]),a._v(" "),t("p",[a._v("由一个版本号（version）、一段描述（description）、一个校验（checksum）组成。版本号必须是惟一的。Versioned migrations 只能按顺序执行一次。")]),a._v(" "),t("p",[a._v("一般用于：")]),a._v(" "),t("ul",[t("li",[a._v("增删改 tables/indexes/foreign keys/enums/UDTs。")]),a._v(" "),t("li",[a._v("引用数据更新")]),a._v(" "),t("li",[a._v("用户数据校正")])]),a._v(" "),t("p",[a._v("Regular 示例：")]),a._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("CREATE")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("TABLE")]),a._v(" car "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),a._v("\n id "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("INT")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("NOT")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[a._v("NULL")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("PRIMARY")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("KEY")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v("\n license_plate "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("VARCHAR")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("NOT")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[a._v("NULL")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v("\n color "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("VARCHAR")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("NOT")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[a._v("NULL")]),a._v("\n"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("ALTER")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("TABLE")]),a._v(" owner "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("ADD")]),a._v(" driver_license_id "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("VARCHAR")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("INSERT")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("INTO")]),a._v(" brand "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),a._v("name"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("VALUES")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v("(")]),t("span",{pre:!0,attrs:{class:"token string"}},[a._v("'DeLorean'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n")])])]),t("h5",{attrs:{id:"undo-migrations"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#undo-migrations"}},[a._v("#")]),a._v(" Undo migrations")]),a._v(" "),t("blockquote",[t("p",[a._v("注：仅专业版支持")])]),a._v(" "),t("p",[a._v("Undo Versioned Migrations 负责撤销 Regular Versioned migrations 的影响。")]),a._v(" "),t("p",[a._v("Undo 示例：")]),a._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("DELETE")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("FROM")]),a._v(" brand "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("WHERE")]),a._v(" name"),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("=")]),t("span",{pre:!0,attrs:{class:"token string"}},[a._v("'DeLorean'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("ALTER")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("TABLE")]),a._v(" owner "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("DROP")]),a._v(" driver_license_id"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("DROP")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("TABLE")]),a._v(" car"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n")])])]),t("h5",{attrs:{id:"repeatable-migrations"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#repeatable-migrations"}},[a._v("#")]),a._v(" Repeatable migrations")]),a._v(" "),t("p",[a._v("由一段描述（description）、一个校验（checksum）组成。Versioned migrations 每次执行后，校验（checksum）会更新。")]),a._v(" "),t("p",[a._v("Repeatable migrations 用于管理可以通过一个文件来维护版本控制的数据库对象。")]),a._v(" "),t("p",[a._v("一般用于：")]),a._v(" "),t("ul",[t("li",[a._v("创建（重建）views/procedures/functions/packages 等。")]),a._v(" "),t("li",[a._v("大量引用数据重新插入")])]),a._v(" "),t("p",[a._v("示例：")]),a._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("CREATE")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("OR")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("REPLACE")]),a._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("VIEW")]),a._v(" blue_cars "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("AS")]),a._v("\n "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("SELECT")]),a._v(" id"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(",")]),a._v(" license_plate "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("FROM")]),a._v(" cars "),t("span",{pre:!0,attrs:{class:"token keyword"}},[a._v("WHERE")]),a._v(" color"),t("span",{pre:!0,attrs:{class:"token operator"}},[a._v("=")]),t("span",{pre:!0,attrs:{class:"token string"}},[a._v("'blue'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[a._v(";")]),a._v("\n")])])]),t("h5",{attrs:{id:"基于-sql-的-migrations"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#基于-sql-的-migrations"}},[a._v("#")]),a._v(" 基于 SQL 的 migrations")]),a._v(" "),t("p",[a._v("migrations 最常用的编写形式就是 SQL。")]),a._v(" "),t("p",[a._v("基于 SQL 的 migrations 一般用于：")]),a._v(" "),t("ul",[t("li",[a._v("DDL 变更（针对 TABLES,VIEWS,TRIGGERS,SEQUENCES 等的 CREATE/ALTER/DROP 操作）")]),a._v(" "),t("li",[a._v("简单的引用数据变更（引用数据表中的 CRUD）")]),a._v(" "),t("li",[a._v("简单的大量数据变更（常规数据表中的 CRUD）")])]),a._v(" "),t("p",[t("strong",[a._v("命名规则")])]),a._v(" "),t("p",[a._v("为了被 Flyway 自动识别，SQL migrations 的文件命名必须遵循规定的模式：")]),a._v(" "),t("p",[t("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/flyway/sql-migrations.png",alt:"img"}})]),a._v(" "),t("ul",[t("li",[t("strong",[a._v("Prefix")]),a._v(" - "),t("code",[a._v("V")]),a._v(" 代表 versioned migrations (可配置), "),t("code",[a._v("U")]),a._v(" 代表 undo migrations (可配置)、 "),t("code",[a._v("R")]),a._v(" 代表 repeatable migrations (可配置)")]),a._v(" "),t("li",[t("strong",[a._v("Version")]),a._v(" - 版本号通过"),t("code",[a._v(".")]),a._v("(点)或"),t("code",[a._v("_")]),a._v("(下划线)分隔 (repeatable migrations 不需要)")]),a._v(" "),t("li",[t("strong",[a._v("Separator")]),a._v(" - "),t("code",[a._v("__")]),a._v(" (两个下划线) (可配置)")]),a._v(" "),t("li",[t("strong",[a._v("Description")]),a._v(" - 下划线或空格分隔的单词")]),a._v(" "),t("li",[t("strong",[a._v("Suffix")]),a._v(" - "),t("code",[a._v(".sql")]),a._v(" (可配置)")])]),a._v(" "),t("h5",{attrs:{id:"基于-java-的-migrations"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#基于-java-的-migrations"}},[a._v("#")]),a._v(" 基于 JAVA 的 migrations")]),a._v(" "),t("p",[a._v("基于 JAVA 的 migrations 适用于使用 SQL 不容易表达的场景：")]),a._v(" "),t("ul",[t("li",[a._v("BLOB 和 CLOB 变更")]),a._v(" "),t("li",[a._v("大量数据的高级变更（重新计算、高级格式变更）")])]),a._v(" "),t("p",[t("strong",[a._v("命名规则")])]),a._v(" "),t("p",[a._v("为了被 Flyway 自动识别，JAVA migrations 的文件命名必须遵循规定的模式：")]),a._v(" "),t("p",[t("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/flyway/java-migrations.png",alt:"img"}})]),a._v(" "),t("ul",[t("li",[t("strong",[a._v("Prefix")]),a._v(" - "),t("code",[a._v("V")]),a._v(" 代表 versioned migrations (可配置), "),t("code",[a._v("U")]),a._v(" 代表 undo migrations (可配置)、 "),t("code",[a._v("R")]),a._v(" 代表 repeatable migrations (可配置)")]),a._v(" "),t("li",[t("strong",[a._v("Version")]),a._v(" - 版本号通过"),t("code",[a._v(".")]),a._v("(点)或"),t("code",[a._v("_")]),a._v("(下划线)分隔 (repeatable migrations 不需要)")]),a._v(" "),t("li",[t("strong",[a._v("Separator")]),a._v(" - "),t("code",[a._v("__")]),a._v(" (两个下划线) (可配置)")]),a._v(" "),t("li",[t("strong",[a._v("Description")]),a._v(" - 下划线或空格分隔的单词")])]),a._v(" "),t("blockquote",[t("p",[a._v("👉 更多细节请参考：https://flywaydb.org/documentation/migrations")])]),a._v(" "),t("h4",{attrs:{id:"callbacks"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#callbacks"}},[a._v("#")]),a._v(" Callbacks")]),a._v(" "),t("blockquote",[t("p",[a._v("注：部分 events 仅专业版支持。")])]),a._v(" "),t("p",[a._v("尽管 Migrations 可能已经满足绝大部分场景的需要，但是某些情况下需要你一遍又一遍的执行相同的行为。这可能会重新编译存储过程，更新视图以及许多其他类型的开销。")]),a._v(" "),t("p",[a._v("因为以上原因，Flyway 提供了 Callbacks，用于在 Migrations 生命周期中添加钩子。")]),a._v(" "),t("p",[a._v("Callbacks 可以用 SQL 或 JAVA 来实现。")]),a._v(" "),t("h5",{attrs:{id:"sql-callbacks"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#sql-callbacks"}},[a._v("#")]),a._v(" SQL Callbacks")]),a._v(" "),t("p",[a._v("SQL Callbacks 的命名规则为：event 名 + SQL migration。")]),a._v(" "),t("p",[a._v("如： "),t("code",[a._v("beforeMigrate.sql")]),a._v(", "),t("code",[a._v("beforeEachMigrate.sql")]),a._v(", "),t("code",[a._v("afterEachMigrate.sql")]),a._v(" 等。")]),a._v(" "),t("p",[a._v("SQL Callbacks 也可以包含描述（description）。这种情况下，SQL Callbacks 文件名 = event 名 + 分隔符 + 描述 + 后缀。例："),t("code",[a._v("beforeRepair__vacuum.sql")])]),a._v(" "),t("p",[a._v("当同一个 event 有多个 SQL callbacks，将按照它们描述（description）的顺序执行。")]),a._v(" "),t("blockquote",[t("p",[t("strong",[a._v("注：")]),a._v(" Flyway 也支持你配置的 "),t("code",[a._v("sqlMigrationSuffixes")]),a._v("。")])]),a._v(" "),t("h5",{attrs:{id:"java-callbacks"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#java-callbacks"}},[a._v("#")]),a._v(" JAVA Callbacks")]),a._v(" "),t("blockquote",[t("p",[a._v("当 SQL Callbacks 不够方便时，才应考虑 JAVA Callbacks。")])]),a._v(" "),t("p",[a._v("JAVA Callbacks 有 3 种形式：")]),a._v(" "),t("ol",[t("li",[t("strong",[a._v("基于 Java 的 Migrations")]),a._v(" - 实现 JdbcMigration、SpringJdbcMigration、MigrationInfoProvider、MigrationChecksumProvider、ConfigurationAware、FlywayConfiguration")]),a._v(" "),t("li",[t("strong",[a._v("基于 Java 的 Callbacks")]),a._v(" - 实现 org.flywaydb.core.api.callback 接口。")]),a._v(" "),t("li",[t("strong",[a._v("自定义 Migration resolvers 和 executors")]),a._v(" - 实现 MigrationResolver、MigrationExecutor、ConfigurationAware、FlywayConfiguration 接口。")])]),a._v(" "),t("blockquote",[t("p",[a._v("👉 更多细节请参考：https://flywaydb.org/documentation/callbacks")])]),a._v(" "),t("h4",{attrs:{id:"error-handlers"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#error-handlers"}},[a._v("#")]),a._v(" Error Handlers")]),a._v(" "),t("blockquote",[t("p",[a._v("注：仅专业版支持。")])]),a._v(" "),t("p",[a._v("（略）")]),a._v(" "),t("h4",{attrs:{id:"dry-runs"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#dry-runs"}},[a._v("#")]),a._v(" Dry Runs")]),a._v(" "),t("blockquote",[t("p",[a._v("注：仅专业版支持。")])]),a._v(" "),t("p",[a._v("（略）")]),a._v(" "),t("h3",{attrs:{id:"命令"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#命令"}},[a._v("#")]),a._v(" 命令")]),a._v(" "),t("p",[a._v("Flyway 的功能主要围绕着 7 个基本命令："),t("a",{attrs:{href:"https://flywaydb.org/documentation/command/migrate",target:"_blank",rel:"noopener noreferrer"}},[a._v("Migrate"),t("OutboundLink")],1),a._v("、"),t("a",{attrs:{href:"https://flywaydb.org/documentation/command/clean",target:"_blank",rel:"noopener noreferrer"}},[a._v("Clean"),t("OutboundLink")],1),a._v("、"),t("a",{attrs:{href:"https://flywaydb.org/documentation/command/info",target:"_blank",rel:"noopener noreferrer"}},[a._v("Info"),t("OutboundLink")],1),a._v("、"),t("a",{attrs:{href:"https://flywaydb.org/documentation/command/validate",target:"_blank",rel:"noopener noreferrer"}},[a._v("Validate"),t("OutboundLink")],1),a._v("、"),t("a",{attrs:{href:"https://flywaydb.org/documentation/command/undo",target:"_blank",rel:"noopener noreferrer"}},[a._v("Undo"),t("OutboundLink")],1),a._v("、"),t("a",{attrs:{href:"https://flywaydb.org/documentation/command/baseline",target:"_blank",rel:"noopener noreferrer"}},[a._v("Baseline"),t("OutboundLink")],1),a._v(" 和 "),t("a",{attrs:{href:"https://flywaydb.org/documentation/command/repair",target:"_blank",rel:"noopener noreferrer"}},[a._v("Repair"),t("OutboundLink")],1),a._v("。")]),a._v(" "),t("p",[a._v("注：各命令的使用方法细节请查阅官方文档。")]),a._v(" "),t("h3",{attrs:{id:"支持的数据库"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#支持的数据库"}},[a._v("#")]),a._v(" 支持的数据库")]),a._v(" "),t("ul",[t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/oracle",target:"_blank",rel:"noopener noreferrer"}},[a._v("Oracle"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/sqlserver",target:"_blank",rel:"noopener noreferrer"}},[a._v("SQL Server"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/db2",target:"_blank",rel:"noopener noreferrer"}},[a._v("DB2"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/mysql",target:"_blank",rel:"noopener noreferrer"}},[a._v("MySQL"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/mariadb",target:"_blank",rel:"noopener noreferrer"}},[a._v("MariaDB"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/postgresql",target:"_blank",rel:"noopener noreferrer"}},[a._v("PostgreSQL"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/redshift",target:"_blank",rel:"noopener noreferrer"}},[a._v("Redshift"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/cockroachdb",target:"_blank",rel:"noopener noreferrer"}},[a._v("CockroachDB"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/saphana",target:"_blank",rel:"noopener noreferrer"}},[a._v("SAP HANA"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/sybasease",target:"_blank",rel:"noopener noreferrer"}},[a._v("Sybase ASE"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/informix",target:"_blank",rel:"noopener noreferrer"}},[a._v("Informix"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/h2",target:"_blank",rel:"noopener noreferrer"}},[a._v("H2"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/hsqldb",target:"_blank",rel:"noopener noreferrer"}},[a._v("HSQLDB"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/derby",target:"_blank",rel:"noopener noreferrer"}},[a._v("Derby"),t("OutboundLink")],1)]),a._v(" "),t("li",[t("a",{attrs:{href:"https://flywaydb.org/documentation/database/sqlite",target:"_blank",rel:"noopener noreferrer"}},[a._v("SQLite"),t("OutboundLink")],1)])]),a._v(" "),t("h2",{attrs:{id:"资料"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#资料"}},[a._v("#")]),a._v(" 资料")]),a._v(" "),t("p",[a._v("| "),t("a",{attrs:{href:"https://github.com/flyway/flyway",target:"_blank",rel:"noopener noreferrer"}},[a._v("Github"),t("OutboundLink")],1),a._v(" | "),t("a",{attrs:{href:"https://flywaydb.org/",target:"_blank",rel:"noopener noreferrer"}},[a._v("官方文档"),t("OutboundLink")],1),a._v(" |")]),a._v(" "),t("h2",{attrs:{id:"传送门"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#传送门"}},[a._v("#")]),a._v(" 🚪 传送门")]),a._v(" "),t("p",[a._v("| "),t("a",{attrs:{href:"https://dunwu.github.io/blog/",target:"_blank",rel:"noopener noreferrer"}},[a._v("钝悟的博客"),t("OutboundLink")],1),a._v(" | "),t("a",{attrs:{href:"https://github.com/dunwu/db-tutorial",target:"_blank",rel:"noopener noreferrer"}},[a._v("db-tutorial 首页"),t("OutboundLink")],1),a._v(" |")])])}),[],!1,null,null,null);t.default=e.exports}}]); \ No newline at end of file diff --git a/assets/js/11.5f47e5c7.js b/assets/js/11.5f47e5c7.js new file mode 100644 index 00000000..bc9db99b --- /dev/null +++ b/assets/js/11.5f47e5c7.js @@ -0,0 +1 @@ +(window.webpackJsonp=window.webpackJsonp||[]).push([[11],{348:function(t,r,e){"use strict";e.r(r);var a=e(4),n=Object(a.a)({},(function(){var t=this,r=t._self._c;return r("ContentSlotsDistributor",{attrs:{"slot-key":t.$parent.slotKey}},[r("h1",{attrs:{id:"数据库中间件和代理"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#数据库中间件和代理"}},[t._v("#")]),t._v(" 数据库中间件和代理")]),t._v(" "),r("h2",{attrs:{id:"📖-内容"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#📖-内容"}},[t._v("#")]),t._v(" 📖 内容")]),t._v(" "),r("ul",[r("li",[r("RouterLink",{attrs:{to:"/12.数据库/02.数据库中间件/01.Shardingsphere/01.ShardingSphere简介.html"}},[t._v("ShardingSphere 简介")])],1),t._v(" "),r("li",[r("RouterLink",{attrs:{to:"/12.数据库/02.数据库中间件/01.Shardingsphere/02.ShardingSphereJdbc.html"}},[t._v("ShardingSphere Jdbc")])],1),t._v(" "),r("li",[r("RouterLink",{attrs:{to:"/12.数据库/02.数据库中间件/02.Flyway.html"}},[t._v("版本管理中间件 Flyway")])],1)]),t._v(" "),r("h2",{attrs:{id:"📚-资料"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#📚-资料"}},[t._v("#")]),t._v(" 📚 资料")]),t._v(" "),r("ul",[r("li",[r("a",{attrs:{href:"https://github.com/seata/seata",target:"_blank",rel:"noopener noreferrer"}},[r("strong",[t._v("Seata")]),r("OutboundLink")],1),t._v(" - 分布式事务中间件。")]),t._v(" "),r("li",[r("a",{attrs:{href:"https://github.com/apache/shardingsphere",target:"_blank",rel:"noopener noreferrer"}},[r("strong",[t._v("ShardingSphere")]),r("OutboundLink")],1),t._v(" - 关系型数据库读写分离、分库分表中间件。")]),t._v(" "),r("li",[r("a",{attrs:{href:"https://github.com/flyway/flyway",target:"_blank",rel:"noopener noreferrer"}},[r("strong",[t._v("Flyway")]),r("OutboundLink")],1),t._v(" - 关系型数据库版本管理中间件。")]),t._v(" "),r("li",[r("a",{attrs:{href:"https://github.com/alibaba/canal",target:"_blank",rel:"noopener noreferrer"}},[r("strong",[t._v("Canal")]),r("OutboundLink")],1),t._v(" - 基于 MySQL 的 binlog，提供增量数据订阅和消费。")]),t._v(" "),r("li",[r("a",{attrs:{href:"https://github.com/twitter/twemproxy",target:"_blank",rel:"noopener noreferrer"}},[r("strong",[t._v("Twemproxy")]),r("OutboundLink")],1),t._v(" - Twitter 开源的一个 Redis 和 Memcache 的中间代理服务。")]),t._v(" "),r("li",[r("a",{attrs:{href:"https://github.com/CodisLabs/codis",target:"_blank",rel:"noopener noreferrer"}},[r("strong",[t._v("Codis")]),r("OutboundLink")],1),t._v(" - Redis 分布式集群方案。")])]),t._v(" "),r("h2",{attrs:{id:"🚪-传送"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#🚪-传送"}},[t._v("#")]),t._v(" 🚪 传送")]),t._v(" "),r("p",[t._v("◾ 💧 "),r("a",{attrs:{href:"https://dunwu.github.io/waterdrop/",target:"_blank",rel:"noopener noreferrer"}},[t._v("钝悟的 IT 知识图谱"),r("OutboundLink")],1),t._v(" ◾ 🎯 "),r("a",{attrs:{href:"https://dunwu.github.io/blog/",target:"_blank",rel:"noopener noreferrer"}},[t._v("钝悟的博客"),r("OutboundLink")],1),t._v(" ◾")])])}),[],!1,null,null,null);r.default=n.exports}}]); \ No newline at end of file diff --git a/assets/js/12.6d2ecf95.js b/assets/js/12.6d2ecf95.js new file mode 100644 index 00000000..f240504e --- /dev/null +++ b/assets/js/12.6d2ecf95.js @@ -0,0 +1 @@ +(window.webpackJsonp=window.webpackJsonp||[]).push([[12],{349:function(t,a,e){"use strict";e.r(a);var _=e(4),v=Object(_.a)({},(function(){var t=this,a=t._self._c;return a("ContentSlotsDistributor",{attrs:{"slot-key":t.$parent.slotKey}},[a("h1",{attrs:{id:"关系型数据库面试"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#关系型数据库面试"}},[t._v("#")]),t._v(" 关系型数据库面试")]),t._v(" "),a("h2",{attrs:{id:"索引和约束"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#索引和约束"}},[t._v("#")]),t._v(" 索引和约束")]),t._v(" "),a("h3",{attrs:{id:"什么是索引"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#什么是索引"}},[t._v("#")]),t._v(" 什么是索引")]),t._v(" "),a("p",[t._v("索引是对数据库表中一或多个列的值进行排序的结构，是帮助数据库高效查询数据的数据结构。")]),t._v(" "),a("h3",{attrs:{id:"索引的优缺点"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#索引的优缺点"}},[t._v("#")]),t._v(" 索引的优缺点")]),t._v(" "),a("p",[t._v("✔ 索引的优点：")]),t._v(" "),a("ul",[a("li",[t._v("索引大大减少了服务器需要扫描的数据量，从而加快检索速度。")]),t._v(" "),a("li",[t._v("支持行级锁的数据库，如 InnoDB 会在访问行的时候加锁。使用索引可以减少访问的行数，从而减少锁的竞争，提高并发。")]),t._v(" "),a("li",[t._v("索引可以帮助服务器避免排序和临时表。")]),t._v(" "),a("li",[t._v("索引可以将随机 I/O 变为顺序 I/O。")]),t._v(" "),a("li",[t._v("唯一索引可以确保每一行数据的唯一性，通过使用索引，可以在查询的过程中使用优化隐藏器，提高系统的性能。")])]),t._v(" "),a("p",[t._v("❌ 索引的缺点：")]),t._v(" "),a("ul",[a("li",[t._v("创建和维护索引要耗费时间，这会随着数据量的增加而增加。")]),t._v(" "),a("li",[a("strong",[t._v("索引需要占用额外的物理空间")]),t._v("，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立组合索引那么需要的空间就会更大。")]),t._v(" "),a("li",[t._v("写操作（"),a("code",[t._v("INSERT")]),t._v("/"),a("code",[t._v("UPDATE")]),t._v("/"),a("code",[t._v("DELETE")]),t._v("）时很可能需要更新索引，导致数据库的写操作性能降低。")])]),t._v(" "),a("h3",{attrs:{id:"何时使用索引"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#何时使用索引"}},[t._v("#")]),t._v(" 何时使用索引")]),t._v(" "),a("p",[t._v("索引能够轻易将查询性能提升几个数量级。")]),t._v(" "),a("p",[t._v("✔ 什么情况"),a("strong",[t._v("适用")]),t._v("索引：")]),t._v(" "),a("ul",[a("li",[t._v("表经常进行 "),a("code",[t._v("SELECT")]),t._v(" 操作；")]),t._v(" "),a("li",[t._v("表的数据量比较大；")]),t._v(" "),a("li",[t._v("列名经常出现在 "),a("code",[t._v("WHERE")]),t._v(" 或连接（"),a("code",[t._v("JOIN")]),t._v("）条件中")])]),t._v(" "),a("p",[t._v("❌ 什么情况"),a("strong",[t._v("不适用")]),t._v("索引：")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("频繁写操作")]),t._v("（ "),a("code",[t._v("INSERT")]),t._v("/"),a("code",[t._v("UPDATE")]),t._v("/"),a("code",[t._v("DELETE")]),t._v(" ）- 需要更新索引空间；")]),t._v(" "),a("li",[a("strong",[t._v("非常小的表")]),t._v(" - 对于非常小的表，大部分情况下简单的全表扫描更高效。")]),t._v(" "),a("li",[t._v("列名不经常出现在 "),a("code",[t._v("WHERE")]),t._v(" 或连接（"),a("code",[t._v("JOIN")]),t._v("）条件中 - 索引就会经常不命中，没有意义，还增加空间开销。")]),t._v(" "),a("li",[t._v("对于特大型表，建立和使用索引的代价将随之增长。可以考虑使用分区技术或 Nosql。")])]),t._v(" "),a("h3",{attrs:{id:"索引的类型"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#索引的类型"}},[t._v("#")]),t._v(" 索引的类型")]),t._v(" "),a("p",[t._v("主流的关系型数据库一般都支持以下索引类型：")]),t._v(" "),a("p",[t._v("从逻辑类型上划分（即一般创建表时设置的索引类型）：")]),t._v(" "),a("ul",[a("li",[t._v("唯一索引（"),a("code",[t._v("UNIQUE")]),t._v("）：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。")]),t._v(" "),a("li",[t._v("主键索引（"),a("code",[t._v("PRIMARY")]),t._v("）：一种特殊的唯一索引，一个表只能有一个主键，不允许有空值。一般是在建表的时候同时创建主键索引。")]),t._v(" "),a("li",[t._v("普通索引（"),a("code",[t._v("INDEX")]),t._v("）：最基本的索引，没有任何限制。")]),t._v(" "),a("li",[t._v("组合索引：多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循最左前缀集合。")])]),t._v(" "),a("p",[t._v("从物理存储上划分：")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("聚集索引")]),t._v("("),a("code",[t._v("Clustered")]),t._v(")：表中各行的物理顺序与键值的逻辑（索引）顺序相同，每个表只能有一个。")]),t._v(" "),a("li",[a("strong",[t._v("非聚集索引")]),t._v("("),a("code",[t._v("Non-clustered")]),t._v(")：非聚集索引指定表的逻辑顺序，也可以视为二级索引。数据存储在一个位置，索引存储在另一个位置，索引中包含指向数据存储位置的指针。可以有多个，小于 249 个。")])]),t._v(" "),a("h3",{attrs:{id:"索引的数据结构"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#索引的数据结构"}},[t._v("#")]),t._v(" 索引的数据结构")]),t._v(" "),a("p",[t._v("主流数据库的索引一般使用的数据结构为：B 树、B+ 树。")]),t._v(" "),a("h4",{attrs:{id:"b-树"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#b-树"}},[t._v("#")]),t._v(" B 树")]),t._v(" "),a("p",[t._v("一棵 M 阶的 B-Tree 满足以下条件：")]),t._v(" "),a("ul",[a("li",[t._v("每个结点至多有 M 个孩子；")]),t._v(" "),a("li",[t._v("除根结点和叶结点外，其它每个结点至少有 M/2 个孩子；")]),t._v(" "),a("li",[t._v("根结点至少有两个孩子（除非该树仅包含一个结点）；")]),t._v(" "),a("li",[t._v("所有叶结点在同一层，叶结点不包含任何关键字信息；")]),t._v(" "),a("li",[t._v("有 K 个关键字的非叶结点恰好包含 K+1 个孩子；")])]),t._v(" "),a("p",[t._v("对于任意结点，其内部的关键字 Key 是升序排列的。每个节点中都包含了 data。")]),t._v(" "),a("div",{attrs:{align:"center"}},[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/RDB/B-TREE.png"}})]),t._v(" "),a("p",[t._v("对于每个结点，主要包含一个关键字数组 "),a("code",[t._v("Key[]")]),t._v("，一个指针数组（指向儿子）"),a("code",[t._v("Son[]")]),t._v("。")]),t._v(" "),a("p",[t._v("在 B-Tree 内，查找的流程是：")]),t._v(" "),a("ol",[a("li",[t._v("使用顺序查找（数组长度较短时）或折半查找方法查找 Key[] 数组，若找到关键字 K，则返回该结点的地址及 K 在 Key[] 中的位置；")]),t._v(" "),a("li",[t._v("否则，可确定 K 在某个 Key[i] 和 Key[i+1] 之间，则从 Son[i] 所指的子结点继续查找，直到在某结点中查找成功；")]),t._v(" "),a("li",[t._v("或直至找到叶结点且叶结点中的查找仍不成功时，查找过程失败。")])]),t._v(" "),a("h4",{attrs:{id:"b-树-2"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#b-树-2"}},[t._v("#")]),t._v(" B+ 树")]),t._v(" "),a("p",[t._v("B+Tree 是 B-Tree 的变种：")]),t._v(" "),a("ul",[a("li",[t._v("每个节点的指针上限为 2d 而不是 2d+1（d 为节点的出度）。")]),t._v(" "),a("li",[t._v("非叶子节点不存储 data，只存储 key；叶子节点不存储指针。")])]),t._v(" "),a("div",{attrs:{align:"center"}},[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/RDB/B+TREE.png"}})]),t._v(" "),a("p",[t._v("由于并不是所有节点都具有相同的域，因此 B+Tree 中叶节点和内节点一般大小不同。这点与 B-Tree 不同，虽然 B-Tree 中不同节点存放的 key 和指针可能数量不一致，但是每个节点的域和上限是一致的，所以在实现中 B-Tree 往往对每个节点申请同等大小的空间。")]),t._v(" "),a("p",[a("strong",[t._v("带有顺序访问指针的 B+Tree")])]),t._v(" "),a("p",[t._v("一般在数据库系统或文件系统中使用的 B+Tree 结构都在经典 B+Tree 的基础上进行了优化，增加了顺序访问指针。")]),t._v(" "),a("div",{attrs:{align:"center"}},[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/RDB/带有顺序访问指针的B+Tree.png"}})]),t._v(" "),a("p",[t._v("在 B+Tree 的每个叶子节点增加一个指向相邻叶子节点的指针，就形成了带有顺序访问指针的 B+Tree。")]),t._v(" "),a("p",[t._v("这个优化的目的是为了提高区间访问的性能，例如上图中如果要查询 key 为从 18 到 49 的所有数据记录，当找到 18 后，只需顺着节点和指针顺序遍历就可以一次性访问到所有数据节点，极大提到了区间查询效率。")]),t._v(" "),a("h4",{attrs:{id:"b-树-vs-b-树"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#b-树-vs-b-树"}},[t._v("#")]),t._v(" B 树 vs. B+ 树")]),t._v(" "),a("ul",[a("li",[t._v("B+ 树更适合外部存储(一般指磁盘存储)，由于内节点(非叶子节点)不存储 data，所以一个节点可以存储更多的内节点，每个节点能索引的范围更大更精确。也就是说使用 B+ 树单次磁盘 IO 的信息量相比较 B 树更大，IO 效率更高。")]),t._v(" "),a("li",[t._v("Mysql 是关系型数据库，经常会按照区间来访问某个索引列，B+ 树的叶子节点间按顺序建立了链指针，加强了区间访问性，所以 B+ 树对索引列上的区间范围查询很友好。而 B 树每个节点的 key 和 data 在一起，无法进行区间查找。")])]),t._v(" "),a("h4",{attrs:{id:"hash"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#hash"}},[t._v("#")]),t._v(" Hash")]),t._v(" "),a("blockquote",[a("p",[t._v("Hash 索引只有精确匹配索引所有列的查询才有效。")])]),t._v(" "),a("p",[t._v("对于每一行数据，对所有的索引列计算一个 "),a("code",[t._v("hashcode")]),t._v("。哈希索引将所有的 "),a("code",[t._v("hashcode")]),t._v(" 存储在索引中，同时在 Hash 表中保存指向每个数据行的指针。")]),t._v(" "),a("p",[t._v("哈希结构索引的优点：")]),t._v(" "),a("ul",[a("li",[t._v("因为索引数据结构紧凑，所以查询速度非常快。")])]),t._v(" "),a("p",[t._v("哈希结构索引的缺点：")]),t._v(" "),a("ul",[a("li",[t._v("哈希索引数据不是按照索引值顺序存储的，所以无法用于排序。")]),t._v(" "),a("li",[t._v("哈希索引不支持部分索引匹配查找。如，在数据列 (A,B) 上建立哈希索引，如果查询只有数据列 A，无法使用该索引。")]),t._v(" "),a("li",[t._v("哈希索引只支持等值比较查询，不支持任何范围查询，如 WHERE price > 100。")]),t._v(" "),a("li",[t._v("哈希索引有可能出现哈希冲突，出现哈希冲突时，必须遍历链表中所有的行指针，逐行比较，直到找到符合条件的行。")])]),t._v(" "),a("h3",{attrs:{id:"索引策略"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#索引策略"}},[t._v("#")]),t._v(" 索引策略")]),t._v(" "),a("h4",{attrs:{id:"索引基本原则"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#索引基本原则"}},[t._v("#")]),t._v(" 索引基本原则")]),t._v(" "),a("ul",[a("li",[t._v("索引不是越多越好，不要为所有列都创建索引。")]),t._v(" "),a("li",[t._v("要尽量避免冗余和重复索引；")]),t._v(" "),a("li",[t._v("要考虑删除未使用的索引；")]),t._v(" "),a("li",[t._v("尽量的扩展索引，不要新建索引；")]),t._v(" "),a("li",[t._v("频繁作为 "),a("code",[t._v("WHERE")]),t._v(" 过滤条件的列应该考虑添加索引")])]),t._v(" "),a("h4",{attrs:{id:"独立的列"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#独立的列"}},[t._v("#")]),t._v(" 独立的列")]),t._v(" "),a("p",[a("strong",[t._v("如果查询中的列不是独立的列，则数据库不会使用索引")]),t._v("。")]),t._v(" "),a("p",[t._v("“独立的列” 是指索引列不能是表达式的一部分，也不能是函数的参数。")]),t._v(" "),a("p",[t._v("❌ 错误示例：")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" actor_id "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" actor "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" actor_id "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("1")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("5")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" TO_DAYS"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("current_date")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),t._v(" TO_DAYS"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("date_col"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("<=")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("10")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),a("h4",{attrs:{id:"前缀索引和索引选择性"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#前缀索引和索引选择性"}},[t._v("#")]),t._v(" 前缀索引和索引选择性")]),t._v(" "),a("p",[t._v("有时候需要索引很长的字符列，这会让索引变得大且慢。")]),t._v(" "),a("p",[t._v("解决方法是：可以索引开始的部分字符，这样可以大大节约索引空间，从而提高索引效率。但这样也会降低索引的选择性。")]),t._v(" "),a("p",[t._v("索引的选择性是指：不重复的索引值和数据表记录总数的比值。最大值为 1，此时每个记录都有唯一的索引与其对应。选择性越高，查询效率也越高。")]),t._v(" "),a("p",[t._v("对于 BLOB/TEXT/VARCHAR 这种文本类型的列，必须使用前缀索引，因为数据库往往不允许索引这些列的完整长度。")]),t._v(" "),a("p",[t._v("要选择足够长的前缀以保证较高的选择性，同时又不能太长（节约空间）。")]),t._v(" "),a("p",[t._v("❌ 低效示例：")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token function"}},[t._v("COUNT")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("AS")]),t._v(" cnt"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" city "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" sakila"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("city_demo\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("GROUP")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BY")]),t._v(" city "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ORDER")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BY")]),t._v(" cnt "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DESC")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("LIMIT")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("10")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),a("p",[t._v("✔ 高效示例：")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token function"}},[t._v("COUNT")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("AS")]),t._v(" cnt"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("LEFT")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("city"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("3")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("AS")]),t._v(" pref "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" sakila"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("city_demo\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("GROUP")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BY")]),t._v(" city "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ORDER")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BY")]),t._v(" cnt "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DESC")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("LIMIT")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("10")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),a("h4",{attrs:{id:"多列索引"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#多列索引"}},[t._v("#")]),t._v(" 多列索引")]),t._v(" "),a("p",[a("strong",[t._v("不要为每个列都创建独立索引")]),t._v("。")]),t._v(" "),a("p",[a("strong",[t._v("将选择性高的列或基数大的列优先排在多列索引最前列")]),t._v("。但有时，也需要考虑 WHERE 子句中的排序、分组和范围条件等因素，这些因素也会对查询性能造成较大影响。")]),t._v(" "),a("p",[t._v("举例来说，有一张 user 表，其中含 name, sex, age 三个列，如果将这三者组合为多列索引，应该用什么样的顺序呢？从选择性高的角度来看："),a("code",[t._v("name > age > sex")]),t._v("。")]),t._v(" "),a("h4",{attrs:{id:"聚簇索引"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#聚簇索引"}},[t._v("#")]),t._v(" 聚簇索引")]),t._v(" "),a("p",[t._v("聚簇索引不是一种单独的索引类型，而是一种数据存储方式。具体细节依赖于实现方式。如 "),a("strong",[t._v("InnoDB 的聚簇索引实际是在同一个结构中保存了 B 树的索引和数据行")]),t._v("。")]),t._v(" "),a("p",[a("strong",[t._v("聚簇表示数据行和相邻的键值紧凑地存储在一起，因为数据紧凑，所以访问快")]),t._v("。因为无法同时把数据行存放在两个不同的地方，所以"),a("strong",[t._v("一个表只能有一个聚簇索引")]),t._v("。")]),t._v(" "),a("p",[t._v("若没有定义主键，InnoDB 会隐式定义一个主键来作为聚簇索引。")]),t._v(" "),a("h4",{attrs:{id:"覆盖索引"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#覆盖索引"}},[t._v("#")]),t._v(" 覆盖索引")]),t._v(" "),a("p",[t._v("索引包含所有需要查询的字段的值。")]),t._v(" "),a("p",[t._v("具有以下优点：")]),t._v(" "),a("ul",[a("li",[t._v("因为索引条目通常远小于数据行的大小，所以若只读取索引，能大大减少数据访问量。")]),t._v(" "),a("li",[t._v("一些存储引擎（例如 MyISAM）在内存中只缓存索引，而数据依赖于操作系统来缓存。因此，只访问索引可以不使用系统调用（通常比较费时）。")]),t._v(" "),a("li",[t._v("对于 InnoDB 引擎，若辅助索引能够覆盖查询，则无需访问主索引。")])]),t._v(" "),a("h4",{attrs:{id:"使用索引扫描来做排序"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#使用索引扫描来做排序"}},[t._v("#")]),t._v(" 使用索引扫描来做排序")]),t._v(" "),a("p",[t._v("Mysql 有两种方式可以生成排序结果：通过排序操作；或者按索引顺序扫描。")]),t._v(" "),a("p",[a("strong",[t._v("索引最好既满足排序，又用于查找行")]),t._v("。这样，就可以使用索引来对结果排序。")]),t._v(" "),a("h4",{attrs:{id:"最左前缀匹配原则"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#最左前缀匹配原则"}},[t._v("#")]),t._v(" 最左前缀匹配原则")]),t._v(" "),a("p",[t._v("MySQL 会一直向右匹配直到遇到范围查询 "),a("code",[t._v("(>,<,BETWEEN,LIKE)")]),t._v(" 就停止匹配。")]),t._v(" "),a("ul",[a("li",[t._v("索引可以简单如一个列(a)，也可以复杂如多个列(a, b, c, d)，即"),a("strong",[t._v("联合索引")]),t._v("。")]),t._v(" "),a("li",[t._v("如果是联合索引，那么 key 也由多个列组成，同时，索引只能用于查找 key 是否"),a("strong",[t._v("存在（相等）")]),t._v("，遇到范围查询(>、<、between、like 左匹配)等就"),a("strong",[t._v("不能进一步匹配")]),t._v("了，后续退化为线性查找。")]),t._v(" "),a("li",[t._v("因此，"),a("strong",[t._v("列的排列顺序决定了可命中索引的列数")]),t._v("。")])]),t._v(" "),a("p",[t._v("例子：")]),t._v(" "),a("ul",[a("li",[t._v("如有索引(a, b, c, d)，查询条件 a = 1 and b = 2 and c > 3 and d = 4，则会在每个节点依次命中 a、b、c，无法命中 d。(很简单：索引命中只能是"),a("strong",[t._v("相等")]),t._v("的情况，不能是范围匹配)")])]),t._v(" "),a("h4",{attrs:{id:"和-in-可以乱序"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#和-in-可以乱序"}},[t._v("#")]),t._v(" = 和 in 可以乱序")]),t._v(" "),a("p",[a("strong",[t._v("不需要考虑=、in 等的顺序")]),t._v("，Mysql 会自动优化这些条件的顺序，以匹配尽可能多的索引列。")]),t._v(" "),a("p",[t._v("例子：如有索引(a, b, c, d)，查询条件 c > 3 and b = 2 and a = 1 and d < 4 与 a = 1 and c > 3 and b = 2 and d < 4 等顺序都是可以的，MySQL 会自动优化为 a = 1 and b = 2 and c > 3 and d < 4，依次命中 a、b、c。")]),t._v(" "),a("h3",{attrs:{id:"约束"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#约束"}},[t._v("#")]),t._v(" 约束")]),t._v(" "),a("p",[t._v("数据库约束（"),a("code",[t._v("CONSTRAINT")]),t._v("）有哪些：")]),t._v(" "),a("ul",[a("li",[a("code",[t._v("NOT NULL")]),t._v(" - 用于控制字段的内容一定不能为空（NULL）。")]),t._v(" "),a("li",[a("code",[t._v("UNIQUE")]),t._v(" - 字段内容不能重复，一个表允许有多个 "),a("code",[t._v("Unique")]),t._v(" 约束。")]),t._v(" "),a("li",[a("code",[t._v("PRIMARY KEY")]),t._v(" - 数据表中对储存数据对象予以唯一和完整标识的数据列或属性的组合，它在一个表中只允许有一个。主键的取值不能为空值（Null）。")]),t._v(" "),a("li",[a("code",[t._v("FOREIGN KEY")]),t._v(" - 在一个表中存在的另一个表的主键称此表的外键。用于预防破坏表之间连接的动作，也能防止非法数据插入外键列，因为它必须是它指向的那个表中的值之一。")]),t._v(" "),a("li",[a("code",[t._v("CHECK")]),t._v(" - 用于控制字段的值范围。")])]),t._v(" "),a("h2",{attrs:{id:"并发控制"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#并发控制"}},[t._v("#")]),t._v(" 并发控制")]),t._v(" "),a("h3",{attrs:{id:"乐观锁和悲观锁"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#乐观锁和悲观锁"}},[t._v("#")]),t._v(" 乐观锁和悲观锁")]),t._v(" "),a("blockquote",[a("ul",[a("li",[t._v("数据库的乐观锁和悲观锁是什么？")]),t._v(" "),a("li",[t._v("数据库的乐观锁和悲观锁如何实现？")])])]),t._v(" "),a("p",[t._v("确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性，"),a("strong",[t._v("乐观锁和悲观锁是并发控制主要采用的技术手段。")])]),t._v(" "),a("ul",[a("li",[a("strong",[a("code",[t._v("悲观锁")])]),t._v(" - 假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作\n"),a("ul",[a("li",[a("strong",[t._v("在查询完数据的时候就把事务锁起来，直到提交事务（COMMIT）")])]),t._v(" "),a("li",[t._v("实现方式：使用数据库中的锁机制")])])]),t._v(" "),a("li",[a("strong",[a("code",[t._v("乐观锁")])]),t._v(" - 假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。\n"),a("ul",[a("li",[a("strong",[t._v("在修改数据的时候把事务锁起来，通过 version 的方式来进行锁定")])]),t._v(" "),a("li",[t._v("实现方式：使用 version 版本或者时间戳")])])])]),t._v(" "),a("h3",{attrs:{id:"行级锁和表级锁"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#行级锁和表级锁"}},[t._v("#")]),t._v(" 行级锁和表级锁")]),t._v(" "),a("blockquote",[a("ul",[a("li",[t._v("什么是行级锁和表级锁？")]),t._v(" "),a("li",[t._v("什么时候用行级锁？什么时候用表级锁？")])])]),t._v(" "),a("p",[t._v("从数据库的锁粒度来看，MySQL 中提供了两种封锁粒度：行级锁和表级锁。")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("表级锁（table lock）")]),t._v(" - 锁定整张表。用户对表进行写操作前，需要先获得写锁，这会阻塞其他用户对该表的所有读写操作。只有没有写锁时，其他用户才能获得读锁，读锁之间不会相互阻塞。")]),t._v(" "),a("li",[a("strong",[t._v("行级锁（row lock）")]),t._v(" - 仅对指定的行记录进行加锁，这样其它进程还是可以对同一个表中的其它记录进行操作。")])]),t._v(" "),a("p",[t._v("二者需要权衡：")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("锁定的数据量越少，锁竞争的发生频率就越小，系统的并发程度就越高")]),t._v("。")]),t._v(" "),a("li",[a("strong",[t._v("锁粒度越小，系统开销就越大")]),t._v("。")])]),t._v(" "),a("p",[t._v("在 "),a("code",[t._v("InnoDB")]),t._v(" 中，行锁是通过给索引上的索引项加锁来实现的。"),a("strong",[t._v("如果没有索引，"),a("code",[t._v("InnoDB")]),t._v(" 将会通过隐藏的聚簇索引来对记录加锁")]),t._v("。")]),t._v(" "),a("h3",{attrs:{id:"读写锁"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#读写锁"}},[t._v("#")]),t._v(" 读写锁")]),t._v(" "),a("blockquote",[a("ul",[a("li",[t._v("什么是读写锁？")])])]),t._v(" "),a("ul",[a("li",[t._v("独享锁（Exclusive），简写为 X 锁，又称写锁。使用方式："),a("code",[t._v("SELECT ... FOR UPDATE;")])]),t._v(" "),a("li",[t._v("共享锁（Shared），简写为 S 锁，又称读锁。使用方式："),a("code",[t._v("SELECT ... LOCK IN SHARE MODE;")])])]),t._v(" "),a("p",[t._v("写锁和读锁的关系，简言之："),a("strong",[t._v("独享锁存在，其他事务就不能做任何操作")]),t._v("。")]),t._v(" "),a("p",[a("strong",[a("code",[t._v("InnoDB")]),t._v(" 下的行锁、间隙锁、next-key 锁统统属于独享锁")]),t._v("。")]),t._v(" "),a("h3",{attrs:{id:"意向锁"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#意向锁"}},[t._v("#")]),t._v(" 意向锁")]),t._v(" "),a("blockquote",[a("ul",[a("li",[t._v("什么是意向锁？")]),t._v(" "),a("li",[t._v("意向锁有什么用？")])])]),t._v(" "),a("p",[t._v("意向锁的作用是："),a("strong",[t._v("当存在表级锁和行级锁的情况下，必须先申请意向锁（表级锁，但不是真的加锁），再获取行级锁")]),t._v("。使用意向锁（Intention Locks）可以更容易地支持多粒度封锁。")]),t._v(" "),a("p",[a("strong",[t._v("意向锁是 "),a("code",[t._v("InnoDB")]),t._v(" 自动加的，不需要用户干预")]),t._v("。")]),t._v(" "),a("h3",{attrs:{id:"mvcc"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#mvcc"}},[t._v("#")]),t._v(" MVCC")]),t._v(" "),a("blockquote",[a("p",[t._v("什么是 MVCC？")]),t._v(" "),a("p",[t._v("MVCC 有什么用？解决了什么问题？")]),t._v(" "),a("p",[t._v("MVCC 的原理是什么？")])]),t._v(" "),a("p",[t._v("多版本并发控制（Multi-Version Concurrency Control, MVCC）是 "),a("code",[t._v("InnoDB")]),t._v(" 存储引擎实现隔离级别的一种具体方式，"),a("strong",[t._v("用于实现提交读和可重复读这两种隔离级别")]),t._v("。而未提交读隔离级别总是读取最新的数据行，要求很低，无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。")]),t._v(" "),a("p",[t._v("MVCC 的思想是：")]),t._v(" "),a("ul",[a("li",[t._v("保存数据在某个时间点的快照。"),a("strong",[t._v("写操作（DELETE、INSERT、UPDATE）更新最新的版本快照，而读操作去读旧版本快照，没有互斥关系")]),t._v("，这一点和 "),a("code",[t._v("CopyOnWrite")]),t._v(" 类似。")]),t._v(" "),a("li",[t._v("脏读和不可重复读最根本的原因是"),a("strong",[t._v("事务读取到其它事务未提交的修改")]),t._v("。在事务进行读取操作时，为了解决脏读和不可重复读问题，"),a("strong",[t._v("MVCC 规定只能读取已经提交的快照")]),t._v("。当然一个事务可以读取自身未提交的快照，这不算是脏读。")])]),t._v(" "),a("h3",{attrs:{id:"next-key-锁"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#next-key-锁"}},[t._v("#")]),t._v(" Next-key 锁")]),t._v(" "),a("p",[t._v("Next-Key 锁是 MySQL 的 "),a("code",[t._v("InnoDB")]),t._v(" 存储引擎的一种锁实现。")]),t._v(" "),a("p",[t._v("MVCC 不能解决幻读问题，"),a("strong",[t._v("Next-Key 锁就是为了解决幻读问题")]),t._v("。在可重复读（"),a("code",[t._v("REPEATABLE READ")]),t._v("）隔离级别下，使用 "),a("strong",[t._v("MVCC + Next-Key 锁")]),t._v(" 可以解决幻读问题。")]),t._v(" "),a("p",[t._v("另外，根据针对 SQL 语句检索条件的不同，加锁又有以下三种情形需要我们掌握。")]),t._v(" "),a("ul",[a("li",[a("code",[t._v("Record Lock")]),t._v(" - "),a("strong",[t._v("行锁对索引项加锁，若没有索引则使用表锁")]),t._v("。")]),t._v(" "),a("li",[a("code",[t._v("Gap Lock")]),t._v(" - 对索引项之间的间隙加锁。锁定索引之间的间隙，但是不包含索引本身。例如当一个事务执行以下语句，其它事务就不能在 t.c 中插入 15。"),a("code",[t._v("SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;")])]),t._v(" "),a("li",[a("code",[t._v("Next-key lock")]),t._v(" -它是 "),a("code",[t._v("Record Lock")]),t._v(" 和 "),a("code",[t._v("Gap Lock")]),t._v(" 的结合，不仅锁定一个记录上的索引，也锁定索引之间的间隙。它锁定一个前开后闭区间。")])]),t._v(" "),a("p",[t._v("索引分为主键索引和非主键索引两种，如果一条 SQL 语句操作了主键索引，MySQL 就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL 会先锁定该非主键索引，再锁定相关的主键索引。在 "),a("code",[t._v("UPDATE")]),t._v("、"),a("code",[t._v("DELETE")]),t._v(" 操作时，MySQL 不仅锁定 "),a("code",[t._v("WHERE")]),t._v(" 条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的 "),a("code",[t._v("next-key lock")]),t._v("。")]),t._v(" "),a("p",[t._v("当两个事务同时执行，一个锁住了主键索引，在等待其他相关索引。另一个锁定了非主键索引，在等待主键索引。这样就会发生死锁。发生死锁后，"),a("code",[t._v("InnoDB")]),t._v(" 一般都可以检测到，并使一个事务释放锁回退，另一个获取锁完成事务。")]),t._v(" "),a("h2",{attrs:{id:"事务"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#事务"}},[t._v("#")]),t._v(" 事务")]),t._v(" "),a("blockquote",[a("p",[t._v("事务简单来说："),a("strong",[t._v("一个 Session 中所进行所有的操作，要么同时成功，要么同时失败")]),t._v("。具体来说，事务指的是满足 ACID 特性的一组操作，可以通过 "),a("code",[t._v("Commit")]),t._v(" 提交一个事务，也可以使用 "),a("code",[t._v("Rollback")]),t._v(" 进行回滚。")])]),t._v(" "),a("p",[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/RDB/%E6%95%B0%E6%8D%AE%E5%BA%93%E4%BA%8B%E5%8A%A1.png",alt:"img"}})]),t._v(" "),a("h3",{attrs:{id:"acid"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#acid"}},[t._v("#")]),t._v(" ACID")]),t._v(" "),a("p",[t._v("ACID — 数据库事务正确执行的四个基本要素：")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("原子性（Atomicity）")])]),t._v(" "),a("li",[a("strong",[t._v("一致性（Consistency）")])]),t._v(" "),a("li",[a("strong",[t._v("隔离性（Isolation）")])]),t._v(" "),a("li",[a("strong",[t._v("持久性（Durability）")])])]),t._v(" "),a("p",[a("strong",[t._v("一个支持事务（Transaction）中的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易。")])]),t._v(" "),a("p",[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/RDB/%E6%95%B0%E6%8D%AE%E5%BA%93ACID.png",alt:"img"}})]),t._v(" "),a("h3",{attrs:{id:"并发一致性问题"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#并发一致性问题"}},[t._v("#")]),t._v(" 并发一致性问题")]),t._v(" "),a("p",[t._v("在并发环境下，事务的隔离性很难保证，因此会出现很多并发一致性问题。")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("丢失修改")])])]),t._v(" "),a("p",[t._v("T"),a("sub",[t._v("1")]),t._v(" 和 T"),a("sub",[t._v("2")]),t._v(" 两个事务都对一个数据进行修改，T"),a("sub",[t._v("1")]),t._v(" 先修改，T"),a("sub",[t._v("2")]),t._v(" 随后修改，T"),a("sub",[t._v("2")]),t._v(" 的修改覆盖了 T"),a("sub",[t._v("1")]),t._v(" 的修改。")]),t._v(" "),a("p",[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/RDB/%E6%95%B0%E6%8D%AE%E5%BA%93%E5%B9%B6%E5%8F%91%E4%B8%80%E8%87%B4%E6%80%A7-%E4%B8%A2%E5%A4%B1%E4%BF%AE%E6%94%B9.png",alt:"img"}})]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("脏读")])])]),t._v(" "),a("p",[t._v("T"),a("sub",[t._v("1")]),t._v(" 修改一个数据，T"),a("sub",[t._v("2")]),t._v(" 随后读取这个数据。如果 T"),a("sub",[t._v("1")]),t._v(" 撤销了这次修改，那么 T"),a("sub",[t._v("2")]),t._v(" 读取的数据是脏数据。")]),t._v(" "),a("p",[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/RDB/%E6%95%B0%E6%8D%AE%E5%BA%93%E5%B9%B6%E5%8F%91%E4%B8%80%E8%87%B4%E6%80%A7-%E8%84%8F%E6%95%B0%E6%8D%AE.png",alt:"img"}})]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("不可重复读")])])]),t._v(" "),a("p",[t._v("T"),a("sub",[t._v("2")]),t._v(" 读取一个数据，T"),a("sub",[t._v("1")]),t._v(" 对该数据做了修改。如果 T"),a("sub",[t._v("2")]),t._v(" 再次读取这个数据，此时读取的结果和第一次读取的结果不同。")]),t._v(" "),a("p",[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/RDB/%E6%95%B0%E6%8D%AE%E5%BA%93%E5%B9%B6%E5%8F%91%E4%B8%80%E8%87%B4%E6%80%A7-%E4%B8%8D%E5%8F%AF%E9%87%8D%E5%A4%8D%E8%AF%BB.png",alt:"img"}})]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("幻读")])])]),t._v(" "),a("p",[t._v("T"),a("sub",[t._v("1")]),t._v(" 读取某个范围的数据，T"),a("sub",[t._v("2")]),t._v(" 在这个范围内插入新的数据，T"),a("sub",[t._v("1")]),t._v(" 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。")]),t._v(" "),a("p",[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/RDB/%E6%95%B0%E6%8D%AE%E5%BA%93%E5%B9%B6%E5%8F%91%E4%B8%80%E8%87%B4%E6%80%A7-%E5%B9%BB%E8%AF%BB.png",alt:"img"}})]),t._v(" "),a("p",[t._v("并发一致性解决方案：")]),t._v(" "),a("p",[t._v("产生并发不一致性问题主要原因是破坏了事务的隔离性，解决方法是通过并发控制来保证隔离性。")]),t._v(" "),a("p",[t._v("并发控制可以通过封锁来实现，但是封锁操作需要用户自己控制，相当复杂。数据库管理系统提供了事务的隔离级别，让用户以一种更轻松的方式处理并发一致性问题。")]),t._v(" "),a("h3",{attrs:{id:"事务隔离"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#事务隔离"}},[t._v("#")]),t._v(" 事务隔离")]),t._v(" "),a("p",[t._v("数据库隔离级别：")]),t._v(" "),a("ul",[a("li",[a("strong",[a("code",[t._v("未提交读（READ UNCOMMITTED）")])]),t._v(" - 事务中的修改，即使没有提交，对其它事务也是可见的。")]),t._v(" "),a("li",[a("strong",[a("code",[t._v("提交读（READ COMMITTED）")])]),t._v(" - 一个事务只能读取已经提交的事务所做的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的。")]),t._v(" "),a("li",[a("strong",[a("code",[t._v("重复读（REPEATABLE READ）")])]),t._v(" - 保证在同一个事务中多次读取同样数据的结果是一样的。")]),t._v(" "),a("li",[a("strong",[a("code",[t._v("串行化（SERIALIXABLE）")])]),t._v(" - 强制事务串行执行。")])]),t._v(" "),a("p",[t._v("数据库隔离级别解决的问题：")]),t._v(" "),a("table",[a("thead",[a("tr",[a("th",{staticStyle:{"text-align":"center"}},[t._v("隔离级别")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("脏读")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("不可重复读")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("幻读")])])]),t._v(" "),a("tbody",[a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("未提交读")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("❌")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("❌")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("❌")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("提交读")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("✔️")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("❌")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("❌")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("可重复读")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("✔️")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("✔️")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("❌")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("可串行化")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("✔️")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("✔️")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("✔️")])])])]),t._v(" "),a("h3",{attrs:{id:"分布式事务"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#分布式事务"}},[t._v("#")]),t._v(" 分布式事务")]),t._v(" "),a("p",[t._v("在单一数据节点中，事务仅限于对单一数据库资源的访问控制，称之为 "),a("strong",[t._v("本地事务")]),t._v("。几乎所有的成熟的关系型数据库都提供了对本地事务的原生支持。")]),t._v(" "),a("p",[a("strong",[t._v("分布式事务")]),t._v(" 是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。")]),t._v(" "),a("h4",{attrs:{id:"两阶段提交"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#两阶段提交"}},[t._v("#")]),t._v(" 两阶段提交")]),t._v(" "),a("p",[t._v("两阶段提交（XA）对业务侵入很小。 它最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于 XA 协议的分布式事务。 XA 协议能够严格保障事务 "),a("code",[t._v("ACID")]),t._v(" 特性。")]),t._v(" "),a("p",[t._v("严格保障事务 "),a("code",[t._v("ACID")]),t._v(" 特性是一把双刃剑。 事务执行在过程中需要将所需资源全部锁定，它更加适用于执行时间确定的短事务。 对于长事务来说，整个事务进行期间对数据的独占，将导致对热点数据依赖的业务系统并发性能衰退明显。 因此，在高并发的性能至上场景中，基于 XA 协议的分布式事务并不是最佳选择。")]),t._v(" "),a("h4",{attrs:{id:"柔性事务"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#柔性事务"}},[t._v("#")]),t._v(" 柔性事务")]),t._v(" "),a("p",[t._v("如果将实现了"),a("code",[t._v("ACID")]),t._v(" 的事务要素的事务称为刚性事务的话，那么基于"),a("code",[t._v("BASE")]),t._v("事务要素的事务则称为柔性事务。 "),a("code",[t._v("BASE")]),t._v("是基本可用、柔性状态和最终一致性这三个要素的缩写。")]),t._v(" "),a("ul",[a("li",[t._v("基本可用（Basically Available）保证分布式事务参与方不一定同时在线。")]),t._v(" "),a("li",[t._v("柔性状态（Soft state）则允许系统状态更新有一定的延时，这个延时对客户来说不一定能够察觉。")]),t._v(" "),a("li",[t._v("而最终一致性（Eventually consistent）通常是通过消息传递的方式保证系统的最终一致性。")])]),t._v(" "),a("p",[t._v("在"),a("code",[t._v("ACID")]),t._v("事务中对隔离性的要求很高，在事务执行过程中，必须将所有的资源锁定。 柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性要求，来换取系统吞吐量的提升。")]),t._v(" "),a("p",[t._v("基于"),a("code",[t._v("ACID")]),t._v("的强一致性事务和基于"),a("code",[t._v("BASE")]),t._v("的最终一致性事务都不是银弹，只有在最适合的场景中才能发挥它们的最大长处。 可通过下表详细对比它们之间的区别，以帮助开发者进行技术选型。")]),t._v(" "),a("h4",{attrs:{id:"事务方案对比"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#事务方案对比"}},[t._v("#")]),t._v(" 事务方案对比")]),t._v(" "),a("table",[a("thead",[a("tr",[a("th",{staticStyle:{"text-align":"left"}}),t._v(" "),a("th",{staticStyle:{"text-align":"left"}},[t._v("本地事务")]),t._v(" "),a("th",{staticStyle:{"text-align":"left"}},[t._v("两（三）阶段事务")]),t._v(" "),a("th",[t._v("柔性事务")])])]),t._v(" "),a("tbody",[a("tr",[a("td",{staticStyle:{"text-align":"left"}},[t._v("业务改造")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("无")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("无")]),t._v(" "),a("td",[t._v("实现相关接口")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"left"}},[t._v("一致性")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("不支持")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("支持")]),t._v(" "),a("td",[t._v("最终一致")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"left"}},[t._v("隔离性")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("不支持")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("支持")]),t._v(" "),a("td",[t._v("业务方保证")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"left"}},[t._v("并发性能")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("无影响")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("严重衰退")]),t._v(" "),a("td",[t._v("略微衰退")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"left"}},[t._v("适合场景")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("业务方处理不一致")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("短事务 & 低并发")]),t._v(" "),a("td",[t._v("长事务 & 高并发")])])])]),t._v(" "),a("h2",{attrs:{id:"分库分表"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#分库分表"}},[t._v("#")]),t._v(" 分库分表")]),t._v(" "),a("h3",{attrs:{id:"什么是分库分表"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#什么是分库分表"}},[t._v("#")]),t._v(" 什么是分库分表")]),t._v(" "),a("blockquote",[a("p",[t._v("什么是分库分表？什么是垂直拆分？什么是水平拆分？什么是 Sharding？")]),t._v(" "),a("p",[t._v("分库分表是为了解决什么问题？")]),t._v(" "),a("p",[t._v("分库分表有什么优点？")]),t._v(" "),a("p",[t._v("分库分表有什么策略？")])]),t._v(" "),a("p",[t._v("分库分表的基本思想就是：把原本完整的数据切分成多个部分，放到不同的数据库或表上。")]),t._v(" "),a("p",[t._v("分库分表一定是为了支撑 "),a("strong",[t._v("高并发、数据量大")]),t._v("两个问题的。")]),t._v(" "),a("h4",{attrs:{id:"垂直切分"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#垂直切分"}},[t._v("#")]),t._v(" 垂直切分")]),t._v(" "),a("blockquote",[a("p",[a("strong",[t._v("垂直切分")]),t._v("，是 "),a("strong",[t._v("把一个有很多字段的表给拆分成多个表，或者是多个库上去")]),t._v("。一般来说，会 "),a("strong",[t._v("将较少的、访问频率较高的字段放到一个表里去")]),t._v("，然后 "),a("strong",[t._v("将较多的、访问频率较低的字段放到另外一个表里去")]),t._v("。因为数据库是有缓存的，访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。")])]),t._v(" "),a("p",[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/snap/image-20200114211639899.png",alt:"image-20200114211639899"}})]),t._v(" "),a("p",[t._v("一般来说，满足下面的条件就可以考虑扩容了：")]),t._v(" "),a("ul",[a("li",[t._v("Mysql 单库超过 5000 万条记录，Oracle 单库超过 1 亿条记录，DB 压力就很大。")]),t._v(" "),a("li",[t._v("单库超过每秒 2000 个并发时，而一个健康的单库最好保持在每秒 1000 个并发左右，不要太大。")])]),t._v(" "),a("p",[t._v("在数据库的层面使用垂直切分将按数据库中表的密集程度部署到不同的库中，例如将原来的电商数据库垂直切分成商品数据库、用户数据库等。")]),t._v(" "),a("h4",{attrs:{id:"水平拆分"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#水平拆分"}},[t._v("#")]),t._v(" 水平拆分")]),t._v(" "),a("blockquote",[a("p",[a("strong",[t._v("水平拆分")]),t._v(" 又称为 "),a("strong",[t._v("Sharding")]),t._v("，它是将同一个表中的记录拆分到多个结构相同的表中。当 "),a("strong",[t._v("单表数据量太大")]),t._v(" 时，会极大影响 "),a("strong",[t._v("SQL 执行的性能")]),t._v(" 。分表是将原来一张表的数据分布到数据库集群的不同节点上，从而缓解单点的压力。")])]),t._v(" "),a("p",[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/snap/image-20200114211203589.png",alt:"image-20200114211203589"}})]),t._v(" "),a("p",[t._v("一般来说，"),a("strong",[t._v("单表有 200 万条数据")]),t._v(" 的时候，性能就会相对差一些了，需要考虑分表了。但是，这也要视具体情况而定，可能是 100 万条，也可能是 500 万条，SQL 越复杂，就最好让单表行数越少。")]),t._v(" "),a("h4",{attrs:{id:"分库分表的优点"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#分库分表的优点"}},[t._v("#")]),t._v(" 分库分表的优点")]),t._v(" "),a("table",[a("thead",[a("tr",[a("th",[t._v("#")]),t._v(" "),a("th",[t._v("分库分表前")]),t._v(" "),a("th",[t._v("分库分表后")])])]),t._v(" "),a("tbody",[a("tr",[a("td",[t._v("并发支撑情况")]),t._v(" "),a("td",[t._v("单机部署，扛不住高并发")]),t._v(" "),a("td",[t._v("从单机到多机，能承受的并发增加了多倍")])]),t._v(" "),a("tr",[a("td",[t._v("磁盘使用情况")]),t._v(" "),a("td",[t._v("单机磁盘容量几乎撑满")]),t._v(" "),a("td",[t._v("拆分为多个库，数据库服务器磁盘使用率大大降低")])]),t._v(" "),a("tr",[a("td",[t._v("SQL 执行性能")]),t._v(" "),a("td",[t._v("单表数据量太大，SQL 越跑越慢")]),t._v(" "),a("td",[t._v("单表数据量减少，SQL 执行效率明显提升")])])])]),t._v(" "),a("h4",{attrs:{id:"分库分表策略"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#分库分表策略"}},[t._v("#")]),t._v(" 分库分表策略")]),t._v(" "),a("ul",[a("li",[t._v("哈希取模："),a("code",[t._v("hash(key) % N")]),t._v(" 或 "),a("code",[t._v("id % N")]),t._v(" "),a("ul",[a("li",[t._v("优点：可以平均分配每个库的数据量和请求压力（负载均衡）。")]),t._v(" "),a("li",[t._v("缺点：扩容麻烦，需要数据迁移。")])])]),t._v(" "),a("li",[t._v("范围：可以按照 ID 或时间划分范围。\n"),a("ul",[a("li",[t._v("优点：扩容简单。")]),t._v(" "),a("li",[t._v("缺点：这种策略容易产生热点问题。")])])]),t._v(" "),a("li",[t._v("映射表：使用单独的一个数据库来存储映射关系。\n"),a("ul",[a("li",[t._v("缺点：存储映射关系的数据库也可能成为性能瓶颈，且一旦宕机，分库分表的数据库就无法工作。所以不建议使用这种策略。")]),t._v(" "),a("li",[t._v("优点：扩容简单，可以解决分布式 ID 问题。")])])])]),t._v(" "),a("h3",{attrs:{id:"分库分表中间件"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#分库分表中间件"}},[t._v("#")]),t._v(" 分库分表中间件")]),t._v(" "),a("blockquote",[a("p",[t._v("❓ 常见问题：")]),t._v(" "),a("ul",[a("li",[a("p",[t._v("你用过哪些分库分表中间件，简单介绍一下？")])]),t._v(" "),a("li",[a("p",[t._v("不同的分库分表中间件各自有什么特性，有什么优缺点？")])]),t._v(" "),a("li",[a("p",[t._v("分库分表中间件技术如何选型？")])])])]),t._v(" "),a("h4",{attrs:{id:"常见的分库分表中间件"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#常见的分库分表中间件"}},[t._v("#")]),t._v(" 常见的分库分表中间件")]),t._v(" "),a("ul",[a("li",[a("a",{attrs:{href:"https://github.com/alibaba/cobar",target:"_blank",rel:"noopener noreferrer"}},[t._v("Cobar"),a("OutboundLink")],1),t._v(" - 阿里 b2b 团队开发和开源的，属于 proxy 层方案，就是介于应用服务器和数据库服务器之间。应用程序通过 JDBC 驱动访问 cobar 集群，cobar 根据 SQL 和分库规则对 SQL 做分解，然后分发到 MySQL 集群不同的数据库实例上执行。早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。")]),t._v(" "),a("li",[a("a",{attrs:{href:"https://github.com/alibaba/tb_tddl",target:"_blank",rel:"noopener noreferrer"}},[t._v("TDDL"),a("OutboundLink")],1),t._v(" - 淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。目前使用的也不多，因为还依赖淘宝的 diamond 配置管理系统。")]),t._v(" "),a("li",[a("a",{attrs:{href:"https://github.com/Qihoo360/Atlas",target:"_blank",rel:"noopener noreferrer"}},[t._v("Atlas"),a("OutboundLink")],1),t._v(" - 360 开源的，属于 proxy 层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以，现在用的公司基本也很少了。")]),t._v(" "),a("li",[a("a",{attrs:{href:"https://github.com/dangdangdotcom/sharding-jdbc",target:"_blank",rel:"noopener noreferrer"}},[t._v("sharding-jdbc"),a("OutboundLink")],1),t._v(" - 当当开源的，属于 client 层方案。确实之前用的还比较多一些，因为 SQL 语法支持也比较多，没有太多限制，而且目前推出到了 2.0 版本，支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从 2017 年一直到现在，是有不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，个人认为算是一个现在也"),a("strong",[t._v("可以选择的方案")]),t._v("。")]),t._v(" "),a("li",[a("a",{attrs:{href:"http://www.mycat.org.cn/",target:"_blank",rel:"noopener noreferrer"}},[t._v("Mycat"),a("OutboundLink")],1),t._v(" - 基于 cobar 改造的，属于 proxy 层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于 sharding jdbc 来说，年轻一些，经历的锤炼少一些。")])]),t._v(" "),a("h4",{attrs:{id:"分库分表中间件技术选型"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#分库分表中间件技术选型"}},[t._v("#")]),t._v(" 分库分表中间件技术选型")]),t._v(" "),a("p",[t._v("建议使用的是 sharding-jdbc 和 mycat。")]),t._v(" "),a("ul",[a("li",[a("p",[a("a",{attrs:{href:"https://github.com/dangdangdotcom/sharding-jdbc",target:"_blank",rel:"noopener noreferrer"}},[t._v("sharding-jdbc"),a("OutboundLink")],1),t._v(" 这种 client 层方案的"),a("strong",[t._v("优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高")]),t._v("，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要"),a("strong",[t._v("耦合")]),t._v(" sharding-jdbc 的依赖。其本质上通过配置多数据源，然后根据设定的分库分表策略，计算路由，将请求发送到计算得到的节点上。")])]),t._v(" "),a("li",[a("p",[a("a",{attrs:{href:"http://www.mycat.org.cn/",target:"_blank",rel:"noopener noreferrer"}},[t._v("Mycat"),a("OutboundLink")],1),t._v(" 这种 proxy 层方案的"),a("strong",[t._v("缺点在于需要部署")]),t._v("，自己运维一套中间件，运维成本高，但是"),a("strong",[t._v("好处在于对于各个项目是透明的")]),t._v("，如果遇到升级之类的都是自己中间件那里搞就行了。")])])]),t._v(" "),a("p",[t._v("通常来说，这两个方案其实都可以选用，但是我个人建议中小型公司选用 sharding-jdbc，client 层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多；但是中大型公司最好还是选用 mycat 这类 proxy 层方案，因为可能大公司系统和项目非常多，团队很大，人员充足，那么最好是专门弄个人来研究和维护 mycat，然后大量项目直接透明使用即可。")]),t._v(" "),a("h3",{attrs:{id:"分库分表的问题"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#分库分表的问题"}},[t._v("#")]),t._v(" 分库分表的问题")]),t._v(" "),a("blockquote",[a("ul",[a("li",[a("p",[t._v("分库分表的常见问题有哪些？")])]),t._v(" "),a("li",[a("p",[t._v("你是如何解决分库分表的问题的？")])])]),t._v(" "),a("p",[t._v("下文一一讲解常见分库分表的问题及解决方案。")])]),t._v(" "),a("h4",{attrs:{id:"分布式事务-2"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#分布式事务-2"}},[t._v("#")]),t._v(" 分布式事务")]),t._v(" "),a("p",[t._v("方案一：使用数据库事务")]),t._v(" "),a("ul",[a("li",[t._v("优点：交由数据库管理，简单有效")]),t._v(" "),a("li",[t._v("缺点：性能代价高，特别是 shard 越来越多时")])]),t._v(" "),a("p",[t._v("方案二：由应用程序和数据库共同控制")]),t._v(" "),a("ul",[a("li",[t._v("原理：将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务，并通过应用程序来总控各个小事务。")]),t._v(" "),a("li",[t._v("优点：性能上有优势")]),t._v(" "),a("li",[t._v("缺点：需要应用程序在事务控制上做灵活设计。如果使用了 spring 的事务管理，改动起来会面临一定的困难。")])]),t._v(" "),a("h4",{attrs:{id:"跨节点-join"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#跨节点-join"}},[t._v("#")]),t._v(" 跨节点 Join")]),t._v(" "),a("p",[t._v("只要是进行切分，跨节点 Join 的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的 id，根据这些 id 发起第二次请求得到关联数据。")]),t._v(" "),a("h4",{attrs:{id:"跨节点的-count-order-by-group-by-以及聚合函数"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#跨节点的-count-order-by-group-by-以及聚合函数"}},[t._v("#")]),t._v(" 跨节点的 count,order by,group by 以及聚合函数")]),t._v(" "),a("p",[t._v("这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。")]),t._v(" "),a("p",[t._v("解决方案：与解决跨节点 join 问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和 join 不同的是每个节点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。")]),t._v(" "),a("p",[t._v("业务角度上的解决方案：")]),t._v(" "),a("ul",[a("li",[t._v("如果是在前台应用提供分页，则限定用户只能看前面 n 页，这个限制在业务上也是合理的，一般看后面的分页意义不大（如果一定要看，可以要求用户缩小范围重新查询）。")]),t._v(" "),a("li",[t._v("如果是后台批处理任务要求分批获取数据，则可以加大 page size，比如每次获取 5000 条记录，有效减少分页数（当然离线访问一般走备库，避免冲击主库）。")]),t._v(" "),a("li",[t._v("分库设计时，一般还有配套大数据平台汇总所有分库的记录，有些分页查询可以考虑走大数据平台。")])]),t._v(" "),a("h4",{attrs:{id:"分布式-id"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#分布式-id"}},[t._v("#")]),t._v(" 分布式 ID")]),t._v(" "),a("p",[t._v("一旦数据库被切分到多个物理节点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的 ID 无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得 ID，以便进行 SQL 路由。")]),t._v(" "),a("p",[t._v("一些常见的主键生成策略：")]),t._v(" "),a("ul",[a("li",[t._v("使用全局唯一 ID：GUID。")]),t._v(" "),a("li",[t._v("为每个分片指定一个 ID 范围。")]),t._v(" "),a("li",[t._v("分布式 ID 生成器 (如 Twitter 的 Snowflake 算法)。")])]),t._v(" "),a("h4",{attrs:{id:"数据迁移-容量规划-扩容等问题"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#数据迁移-容量规划-扩容等问题"}},[t._v("#")]),t._v(" 数据迁移，容量规划，扩容等问题")]),t._v(" "),a("p",[t._v("来自淘宝综合业务平台团队，它利用对 2 的倍数取余具有向前兼容的特性（如对 4 取余得 1 的数对 2 取余也是 1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了 Sharding 扩容的难度。")]),t._v(" "),a("h2",{attrs:{id:"集群"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#集群"}},[t._v("#")]),t._v(" 集群")]),t._v(" "),a("blockquote",[a("p",[t._v("这个专题需要根据熟悉哪个数据库而定，但是主流、成熟的数据库都会实现一些基本功能，只是实现方式、策略上有所差异。由于本人较为熟悉 Mysql，所以下面主要介绍 Mysql 系统架构问题。")])]),t._v(" "),a("h3",{attrs:{id:"复制机制"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#复制机制"}},[t._v("#")]),t._v(" 复制机制")]),t._v(" "),a("p",[t._v("Mysql 支持两种复制：基于行的复制和基于语句的复制。")]),t._v(" "),a("p",[t._v("这两种方式都是在主库上记录二进制日志（binlog），然后在从库上以异步方式更新主库上的日志记录。这意味着：复制过程存在时延，这段时间内，主从数据可能不一致（即最终一致性）。")]),t._v(" "),a("p",[t._v("主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("binlog 线程")]),t._v(" ：负责将主服务器上的数据更改写入二进制文件（binlog）中。")]),t._v(" "),a("li",[a("strong",[t._v("I/O 线程")]),t._v(" ：负责从主服务器上读取二进制日志文件，并写入从服务器的日志中。")]),t._v(" "),a("li",[a("strong",[t._v("SQL 线程")]),t._v(" ：负责读取日志并执行 SQL 语句以更新数据。")])]),t._v(" "),a("p",[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/mysql/master-slave.png",alt:"img"}})]),t._v(" "),a("h3",{attrs:{id:"读写分离"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#读写分离"}},[t._v("#")]),t._v(" 读写分离")]),t._v(" "),a("p",[t._v("主服务器用来处理写操作以及实时性要求比较高的读操作，而从服务器用来处理读操作。")]),t._v(" "),a("p",[t._v("读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。")]),t._v(" "),a("p",[t._v("MySQL 读写分离能提高性能的原因在于：")]),t._v(" "),a("ul",[a("li",[t._v("主从服务器负责各自的读和写，极大程度缓解了锁的争用；")]),t._v(" "),a("li",[t._v("从服务器可以配置 "),a("code",[t._v("MyISAM")]),t._v(" 引擎，提升查询性能以及节约系统开销；")]),t._v(" "),a("li",[t._v("增加冗余，提高可用性。")])]),t._v(" "),a("p",[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/mysql/master-slave-proxy.png",alt:"img"}})]),t._v(" "),a("h2",{attrs:{id:"数据库优化"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#数据库优化"}},[t._v("#")]),t._v(" 数据库优化")]),t._v(" "),a("p",[t._v("数据库优化的路线一般为：SQL 优化、结构优化、配置优化、硬件优化。前两个方向一般是普通开发的考量点，而后两个方向一般是 DBA 的考量点。")]),t._v(" "),a("h3",{attrs:{id:"sql-优化"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#sql-优化"}},[t._v("#")]),t._v(" SQL 优化")]),t._v(" "),a("blockquote",[a("p",[t._v("SQL 优化是数据库优化的最常见、最初级手段。")]),t._v(" "),a("p",[t._v("在执行 SQL 语句，语句中字段的顺序、查询策略等都可能会影响到 SQL 的执行性能。")])]),t._v(" "),a("h4",{attrs:{id:"执行计划"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#执行计划"}},[t._v("#")]),t._v(" 执行计划")]),t._v(" "),a("p",[t._v("如何检验修改后的 SQL 确实有优化效果？这就需要用到执行计划（"),a("code",[t._v("EXPLAIN")]),t._v("）。")]),t._v(" "),a("p",[t._v("使用执行计划 "),a("code",[t._v("EXPLAIN")]),t._v(" 用来分析 "),a("code",[t._v("SELECT")]),t._v(" 查询效率，开发人员可以通过分析 "),a("code",[t._v("EXPLAIN")]),t._v(" 结果来优化查询语句。")]),t._v(" "),a("p",[t._v("比较重要的字段有：")]),t._v(" "),a("ul",[a("li",[a("code",[t._v("select_type")]),t._v(" - 查询类型，有简单查询、联合查询、子查询等")]),t._v(" "),a("li",[a("code",[t._v("key")]),t._v(" - 使用的索引")]),t._v(" "),a("li",[a("code",[t._v("rows")]),t._v(" - 扫描的行数")])]),t._v(" "),a("blockquote",[a("p",[t._v("更多内容请参考："),a("a",{attrs:{href:"https://segmentfault.com/a/1190000008131735",target:"_blank",rel:"noopener noreferrer"}},[t._v("MySQL 性能优化神器 Explain 使用分析"),a("OutboundLink")],1)])]),t._v(" "),a("h4",{attrs:{id:"访问数据优化"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#访问数据优化"}},[t._v("#")]),t._v(" 访问数据优化")]),t._v(" "),a("p",[t._v("减少请求的数据量：")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("只返回必要的列")]),t._v(" - 不要查询不需要的列，尽量避免使用 "),a("code",[t._v("SELECT *")]),t._v(" 语句。")]),t._v(" "),a("li",[a("strong",[t._v("只返回必要的行")]),t._v(" - 使用 "),a("code",[t._v("WHERE")]),t._v(" 语句进行查询过滤，有时候也需要使用 "),a("code",[t._v("LIMIT")]),t._v(" 语句来限制返回的数据。")]),t._v(" "),a("li",[a("strong",[t._v("缓存重复查询的数据")]),t._v(" - 使用缓存可以避免在数据库中进行查询，特别要查询的数据经常被重复查询，缓存可以带来的查询性能提升将会是非常明显的。")])]),t._v(" "),a("p",[t._v("减少服务器端扫描的行数：")]),t._v(" "),a("ul",[a("li",[t._v("最有效的方式是"),a("strong",[t._v("使用索引来覆盖查询")]),t._v("（即 "),a("code",[t._v("WHERE")]),t._v(" 后的过滤查询字段最好是索引字段）。")])]),t._v(" "),a("h4",{attrs:{id:"重构查询方式"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#重构查询方式"}},[t._v("#")]),t._v(" 重构查询方式")]),t._v(" "),a("h5",{attrs:{id:"切分查询"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#切分查询"}},[t._v("#")]),t._v(" 切分查询")]),t._v(" "),a("p",[t._v("一个大查询如果一次性执行的话，可能一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[t._v("DELEFT "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" messages "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("create")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("<")]),t._v(" DATE_SUB"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),a("span",{pre:!0,attrs:{class:"token function"}},[t._v("NOW")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INTERVAL")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("3")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("MONTH")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[t._v("rows_affected "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("0")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("do")]),t._v(" {\n rows_affected "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" do_query"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("\n "),a("span",{pre:!0,attrs:{class:"token string"}},[t._v('"DELETE FROM messages WHERE create < DATE_SUB(NOW(), INTERVAL 3 MONTH) LIMIT 10000"')]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n} "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("while")]),t._v(" rows_affected "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v(">")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("0")]),t._v("\n")])])]),a("h5",{attrs:{id:"分解关联查询"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#分解关联查询"}},[t._v("#")]),t._v(" 分解关联查询")]),t._v(" "),a("p",[t._v("将一个大连接查询（JOIN）分解成对每一个表进行一次单表查询，然后将结果在应用程序中进行关联，这样做的好处有：")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("缓存更高效")]),t._v("。对于连接查询，如果其中一个表发生变化，那么整个查询缓存就无法使用。而分解后的多个查询，即使其中一个表发生变化，对其它表的查询缓存依然可以使用。")]),t._v(" "),a("li",[t._v("分解成多个单表查询，这些单表查询的缓存结果更可能被其它查询使用到，从而"),a("strong",[t._v("减少冗余记录的查询")]),t._v("。")]),t._v(" "),a("li",[a("strong",[t._v("减少锁竞争")]),t._v("；")]),t._v(" "),a("li",[a("strong",[t._v("在应用层进行连接，可以更容易对数据库进行拆分")]),t._v("，从而更容易做到高性能和可扩展。")]),t._v(" "),a("li",[a("strong",[t._v("查询本身效率也可能会有所提升")]),t._v("。例如下面的例子中，使用 "),a("code",[t._v("IN()")]),t._v(" 代替连接查询，可以让 MySQL 按照 ID 顺序进行查询，这可能比随机的连接要更高效。")])]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" tag\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("JOIN")]),t._v(" tag_post "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ON")]),t._v(" tag_post"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("tag_id"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v("tag"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("id\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("JOIN")]),t._v(" post "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ON")]),t._v(" tag_post"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("post_id"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v("post"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("id\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" tag"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("tag"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),a("span",{pre:!0,attrs:{class:"token string"}},[t._v("'mysql'")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" tag "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" tag"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),a("span",{pre:!0,attrs:{class:"token string"}},[t._v("'mysql'")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" tag_post "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" tag_id"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("1234")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" post "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" post"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("id "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("IN")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("123")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("456")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("567")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("9098")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("8904")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),a("h4",{attrs:{id:"sql-语句细节"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#sql-语句细节"}},[t._v("#")]),t._v(" SQL 语句细节")]),t._v(" "),a("h5",{attrs:{id:"选择最有效率的表名顺序"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#选择最有效率的表名顺序"}},[t._v("#")]),t._v(" 选择最有效率的表名顺序")]),t._v(" "),a("p",[t._v("数据库按照"),a("strong",[t._v("从右到左的顺序处理 FROM 子句中的表名，FROM 子句中写在最后的表将被最先处理")]),t._v("。")]),t._v(" "),a("p",[t._v("在 "),a("code",[t._v("FROM")]),t._v(" 子句中包含多个表的情况下：")]),t._v(" "),a("ul",[a("li",[t._v("如果多个表是完全"),a("strong",[t._v("无关系")]),t._v("的话，将记录和列名最少的表，写在最后，然后依次类推。也就是说："),a("strong",[t._v("选择记录条数最少的表放在最后")]),t._v("。")])]),t._v(" "),a("p",[t._v("如果有 3 个以上的表连接查询：")]),t._v(" "),a("ul",[a("li",[t._v("如果多个表是"),a("strong",[t._v("有关系")]),t._v("的话，将引用最多的表，放在最后，然后依次类推。也就是说："),a("strong",[t._v("被其他表所引用的表放在最后")]),t._v("。")])]),t._v(" "),a("p",[t._v("例如：查询员工的编号，姓名，工资，工资等级，部门名")]),t._v(" "),a("p",[a("strong",[t._v("emp 表被引用得最多，记录数也是最多，因此放在 form 字句的最后面")])]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("select")]),t._v(" emp"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("empno"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("emp"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("ename"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("emp"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("sal"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("salgrade"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("grade"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("dept"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("dname\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("from")]),t._v(" salgrade"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("dept"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("emp\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("where")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("emp"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("deptno "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" dept"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("deptno"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("and")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("emp"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("sal "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("between")]),t._v(" salgrade"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("losal "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("and")]),t._v(" salgrade"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("hisal"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n")])])]),a("h5",{attrs:{id:"where-子句中的连接顺序"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#where-子句中的连接顺序"}},[t._v("#")]),t._v(" WHERE 子句中的连接顺序")]),t._v(" "),a("p",[t._v("数据库按照"),a("strong",[t._v("从右到左的顺序解析 "),a("code",[t._v("WHERE")]),t._v(" 子句")]),t._v("。")]),t._v(" "),a("p",[t._v("因此，"),a("strong",[t._v("表之间的连接必须写在其他 WHERE 条件的左边")]),t._v("，那些"),a("strong",[t._v("可以过滤掉最大数量记录的条件必须写在 WHERE 子句的之右")]),t._v("。")]),t._v(" "),a("p",[a("strong",[t._v("emp.sal 可以过滤多条记录，写在 WHERE 字句的最右边")])]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("select")]),t._v(" emp"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("empno"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("emp"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("ename"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("emp"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("sal"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("dept"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("dname\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("from")]),t._v(" dept"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("emp\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("where")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("emp"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("deptno "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" dept"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("deptno"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("and")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("emp"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("sal "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v(">")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("1500")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n")])])]),a("h5",{attrs:{id:"select-子句中避免使用-号"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#select-子句中避免使用-号"}},[t._v("#")]),t._v(" SELECT 子句中避免使用 "),a("code",[t._v("*")]),t._v(" 号")]),t._v(" "),a("p",[t._v("我们当时学习的时候，“*” 号是可以获取表中全部的字段数据的。")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("但是它要通过查询数据字典完成的，这意味着将耗费更多的时间")])]),t._v(" "),a("li",[t._v("使用*号写出来的 SQL 语句也不够直观。")])]),t._v(" "),a("hr"),t._v(" "),a("h5",{attrs:{id:"用-truncate-替代-delete"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#用-truncate-替代-delete"}},[t._v("#")]),t._v(" 用 TRUNCATE 替代 DELETE")]),t._v(" "),a("p",[t._v("如果需要"),a("strong",[t._v("清空所有表记录")]),t._v("，使用 TRUNCATE 比 DELETE 执行效率高：")]),t._v(" "),a("p",[a("strong",[t._v("DELETE 是一条一条记录的删除，而 Truncate 是将整个表删除，仅保留表结构")])]),t._v(" "),a("h5",{attrs:{id:"使用内部函数提高-sql-效率"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#使用内部函数提高-sql-效率"}},[t._v("#")]),t._v(" 使用内部函数提高 SQL 效率")]),t._v(" "),a("p",[a("strong",[t._v("例如使用 mysql 的 concat() 函数会比使用 "),a("code",[t._v("||")]),t._v(" 拼接速度快，因为 concat() 函数已经被 mysql 优化过了。")])]),t._v(" "),a("h5",{attrs:{id:"使用表或列的别名"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#使用表或列的别名"}},[t._v("#")]),t._v(" 使用表或列的别名")]),t._v(" "),a("p",[t._v("如果表或列的名称太长了，使用一些简短的别名也能稍微提高一些 SQL 的性能。毕竟要扫描的字符长度就变少了。")]),t._v(" "),a("h5",{attrs:{id:"sql-关键字大写"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#sql-关键字大写"}},[t._v("#")]),t._v(" SQL 关键字大写")]),t._v(" "),a("p",[t._v("我们在编写 SQL 的时候，官方推荐的是使用大写来写关键字，"),a("strong",[t._v("因为 Oracle 服务器总是先将小写字母转成大写后，才执行")])]),t._v(" "),a("h5",{attrs:{id:"用-替代"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#用-替代"}},[t._v("#")]),t._v(" 用 "),a("code",[t._v(">=")]),t._v(" 替代 "),a("code",[t._v(">")])]),t._v(" "),a("p",[t._v("❌ 低效方式：")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 首先定位到DEPTNO=3的记录并且扫描到第一个DEPT大于3的记录")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" EMP "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" DEPTNO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v(">")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("3")]),t._v("\n")])])]),a("p",[t._v("✔ 高效方式：")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 直接跳到第一个DEPT等于4的记录")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" EMP "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" DEPTNO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v(">=")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("4")]),t._v("\n")])])]),a("h5",{attrs:{id:"用-in-替代-or"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#用-in-替代-or"}},[t._v("#")]),t._v(" 用 IN 替代 OR")]),t._v(" "),a("p",[t._v("❌ 低效方式：")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("select")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("from")]),t._v(" emp "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("where")]),t._v(" sal "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("1500")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("or")]),t._v(" sal "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("3000")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("or")]),t._v(" sal "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("800")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),a("p",[t._v("✔ 高效方式：")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("select")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("from")]),t._v(" emp "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("where")]),t._v(" sal "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("in")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("1500")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("3000")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("800")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),a("h5",{attrs:{id:"总是使用索引的第一个列"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#总是使用索引的第一个列"}},[t._v("#")]),t._v(" 总是使用索引的第一个列")]),t._v(" "),a("p",[t._v("如果索引是建立在多个列上，只有在它的第一个列被 WHERE 子句引用时，优化器才会选择使用该索引。 当只引用索引的第二个列时，不引用索引的第一个列时，优化器使用了全表扫描而忽略了索引")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("create")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("index")]),t._v(" emp_sal_job_idex\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("on")]),t._v(" emp"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("sal"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("job"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token comment"}},[t._v("----------------------------------")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("select")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("from")]),t._v(" emp\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("where")]),t._v(" job "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("!=")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token string"}},[t._v("'SALES'")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),a("h5",{attrs:{id:"sql-关键字尽量大写"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#sql-关键字尽量大写"}},[t._v("#")]),t._v(" SQL 关键字尽量大写")]),t._v(" "),a("p",[t._v("SQL 关键字尽量大写，如：Oracle 默认会将 SQL 语句中的关键字转为大写后在执行。")]),t._v(" "),a("h3",{attrs:{id:"结构优化"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#结构优化"}},[t._v("#")]),t._v(" 结构优化")]),t._v(" "),a("p",[t._v("数据库结构优化可以从以下方向着手：")]),t._v(" "),a("ul",[a("li",[t._v("数据类型优化")]),t._v(" "),a("li",[t._v("范式和反范式优化")]),t._v(" "),a("li",[t._v("索引优化 - 细节请看索引和约束章节")]),t._v(" "),a("li",[t._v("分库分表 - 细节请看分库分表章节")])]),t._v(" "),a("h4",{attrs:{id:"数据类型优化原则"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#数据类型优化原则"}},[t._v("#")]),t._v(" 数据类型优化原则")]),t._v(" "),a("ul",[a("li",[t._v("更小的通常更好")]),t._v(" "),a("li",[t._v("简单就好，如整型比字符型操作代价低")]),t._v(" "),a("li",[t._v("尽量避免 NULL")])]),t._v(" "),a("h4",{attrs:{id:"范式和反范式"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#范式和反范式"}},[t._v("#")]),t._v(" 范式和反范式")]),t._v(" "),a("p",[t._v("范式和反范式各有利弊，需要根据实际情况权衡。")]),t._v(" "),a("p",[t._v("范式化的目标是"),a("strong",[t._v("尽力减少冗余列，节省空间")]),t._v("。")]),t._v(" "),a("ul",[a("li",[a("p",[t._v("范式化的优点是：")]),t._v(" "),a("ul",[a("li",[t._v("减少冗余列，要写的数据就少，写操作的性能提高；")]),t._v(" "),a("li",[t._v("检索列数据时，"),a("code",[t._v("DISTINCT")]),t._v(" 或 "),a("code",[t._v("GROUP BY")]),t._v(" 操作减少。")])])]),t._v(" "),a("li",[a("p",[t._v("范式化的缺点是：增加关联查询。")])])]),t._v(" "),a("p",[t._v("反范式化的目标是"),a("strong",[t._v("适当增加冗余列，以避免关联查询")]),t._v("。")]),t._v(" "),a("p",[t._v("反范式化的缺点是：")]),t._v(" "),a("ul",[a("li",[t._v("冗余列增多，空间变大，写操作性能下降；")]),t._v(" "),a("li",[t._v("检索列数据时，DISTINCT 或 GROUP BY 操作变多；")])]),t._v(" "),a("h3",{attrs:{id:"配置优化"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#配置优化"}},[t._v("#")]),t._v(" 配置优化")]),t._v(" "),a("blockquote",[a("p",[t._v("配置优化主要是针对 Mysql 服务器，例如："),a("code",[t._v("max_connections")]),t._v("、"),a("code",[t._v("max_heap_table_size")]),t._v("、"),a("code",[t._v("open_files_limit")]),t._v("、"),a("code",[t._v("max_allowed_packet")]),t._v(" 等等。")]),t._v(" "),a("p",[t._v("在不同环境，不同场景下，应该酌情使用合理的配置。这种优化比较考验 Mysql 运维经验，一般是 DBA 的考量，普通开发接触的较少。")]),t._v(" "),a("p",[t._v("Mysql 配置说明请参考："),a("RouterLink",{attrs:{to:"/12.数据库/03.关系型数据库/01.综合/sql/mysql/mysql-config.html"}},[t._v("Mysql 服务器配置说明")])],1)]),t._v(" "),a("h3",{attrs:{id:"硬件优化"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#硬件优化"}},[t._v("#")]),t._v(" 硬件优化")]),t._v(" "),a("p",[t._v("数据库扩容、使用高配设备等等。核心就是一个字：钱。")]),t._v(" "),a("h2",{attrs:{id:"数据库理论"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#数据库理论"}},[t._v("#")]),t._v(" 数据库理论")]),t._v(" "),a("h3",{attrs:{id:"函数依赖"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#函数依赖"}},[t._v("#")]),t._v(" 函数依赖")]),t._v(" "),a("p",[t._v("记 A->B 表示 A 函数决定 B，也可以说 B 函数依赖于 A。")]),t._v(" "),a("p",[t._v("如果 {A1，A2，... ，An} 是关系的一个或多个属性的集合，该集合函数决定了关系的其它所有属性并且是最小的，那么该集合就称为键码。")]),t._v(" "),a("p",[t._v("对于 A->B，如果能找到 A 的真子集 A'，使得 A'-> B，那么 A->B 就是部分函数依赖，否则就是完全函数依赖；")]),t._v(" "),a("p",[t._v("对于 A->B，B->C，则 A->C 是一个传递依赖。")]),t._v(" "),a("h3",{attrs:{id:"异常"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#异常"}},[t._v("#")]),t._v(" 异常")]),t._v(" "),a("p",[t._v("以下的学生课程关系的函数依赖为 Sno, Cname -> Sname, Sdept, Mname, Grade，键码为 {Sno, Cname}。也就是说，确定学生和课程之后，就能确定其它信息。")]),t._v(" "),a("table",[a("thead",[a("tr",[a("th",{staticStyle:{"text-align":"center"}},[t._v("Sno")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Sname")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Sdept")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Mname")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Cname")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Grade")])])]),t._v(" "),a("tbody",[a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("90")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("80")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("100")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("3")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-3")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("95")])])])]),t._v(" "),a("p",[t._v("不符合范式的关系，会产生很多异常，主要有以下四种异常：")]),t._v(" "),a("ul",[a("li",[t._v("冗余数据：例如 学生-2 出现了两次。")]),t._v(" "),a("li",[t._v("修改异常：修改了一个记录中的信息，但是另一个记录中相同的信息却没有被修改。")]),t._v(" "),a("li",[t._v("删除异常：删除一个信息，那么也会丢失其它信息。例如如果删除了 课程-1，需要删除第一行和第三行，那么 学生-1 的信息就会丢失。")]),t._v(" "),a("li",[t._v("插入异常，例如想要插入一个学生的信息，如果这个学生还没选课，那么就无法插入。")])]),t._v(" "),a("h3",{attrs:{id:"范式"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#范式"}},[t._v("#")]),t._v(" 范式")]),t._v(" "),a("p",[t._v("范式理论是为了解决以上提到四种异常。")]),t._v(" "),a("p",[t._v("高级别范式的依赖于低级别的范式，1NF 是最低级别的范式。")]),t._v(" "),a("div",{attrs:{align:"center"}},[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/RDB/数据库范式.png"}})]),t._v(" "),a("h4",{attrs:{id:"第一范式-1nf"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#第一范式-1nf"}},[t._v("#")]),t._v(" 第一范式 (1NF)")]),t._v(" "),a("p",[t._v("属性不可分。")]),t._v(" "),a("h4",{attrs:{id:"第二范式-2nf"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#第二范式-2nf"}},[t._v("#")]),t._v(" 第二范式 (2NF)")]),t._v(" "),a("ul",[a("li",[a("p",[t._v("每个非主属性完全函数依赖于键码。")])]),t._v(" "),a("li",[a("p",[t._v("可以通过分解来满足。")])])]),t._v(" "),a("p",[a("strong",[t._v("分解前")])]),t._v(" "),a("table",[a("thead",[a("tr",[a("th",{staticStyle:{"text-align":"center"}},[t._v("Sno")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Sname")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Sdept")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Mname")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Cname")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Grade")])])]),t._v(" "),a("tbody",[a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("90")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("80")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("100")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("3")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-3")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("95")])])])]),t._v(" "),a("p",[t._v("以上学生课程关系中，{Sno, Cname} 为键码，有如下函数依赖：")]),t._v(" "),a("ul",[a("li",[t._v("Sno -> Sname, Sdept")]),t._v(" "),a("li",[t._v("Sdept -> Mname")]),t._v(" "),a("li",[t._v("Sno, Cname-> Grade")])]),t._v(" "),a("p",[t._v("Grade 完全函数依赖于键码，它没有任何冗余数据，每个学生的每门课都有特定的成绩。")]),t._v(" "),a("p",[t._v("Sname, Sdept 和 Mname 都部分依赖于键码，当一个学生选修了多门课时，这些数据就会出现多次，造成大量冗余数据。")]),t._v(" "),a("p",[a("strong",[t._v("分解后")])]),t._v(" "),a("p",[t._v("关系-1")]),t._v(" "),a("table",[a("thead",[a("tr",[a("th",{staticStyle:{"text-align":"center"}},[t._v("Sno")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Sname")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Sdept")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Mname")])])]),t._v(" "),a("tbody",[a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-1")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-2")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("3")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-3")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-2")])])])]),t._v(" "),a("p",[t._v("有以下函数依赖：")]),t._v(" "),a("ul",[a("li",[t._v("Sno -> Sname, Sdept, Mname")]),t._v(" "),a("li",[t._v("Sdept -> Mname")])]),t._v(" "),a("p",[t._v("关系-2")]),t._v(" "),a("table",[a("thead",[a("tr",[a("th",{staticStyle:{"text-align":"center"}},[t._v("Sno")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Cname")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Grade")])])]),t._v(" "),a("tbody",[a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("90")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("80")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("100")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("3")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("课程-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("95")])])])]),t._v(" "),a("p",[t._v("有以下函数依赖：")]),t._v(" "),a("ul",[a("li",[t._v("Sno, Cname -> Grade")])]),t._v(" "),a("h4",{attrs:{id:"第三范式-3nf"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#第三范式-3nf"}},[t._v("#")]),t._v(" 第三范式 (3NF)")]),t._v(" "),a("ul",[a("li",[t._v("非主属性不传递依赖于键码。")])]),t._v(" "),a("p",[t._v("上面的 关系-1 中存在以下传递依赖：Sno -> Sdept -> Mname，可以进行以下分解：")]),t._v(" "),a("p",[t._v("关系-11")]),t._v(" "),a("table",[a("thead",[a("tr",[a("th",{staticStyle:{"text-align":"center"}},[t._v("Sno")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Sname")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Sdept")])])]),t._v(" "),a("tbody",[a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-1")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-2")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("3")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学生-3")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-2")])])])]),t._v(" "),a("p",[t._v("关系-12")]),t._v(" "),a("table",[a("thead",[a("tr",[a("th",{staticStyle:{"text-align":"center"}},[t._v("Sdept")]),t._v(" "),a("th",{staticStyle:{"text-align":"center"}},[t._v("Mname")])])]),t._v(" "),a("tbody",[a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-1")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-1")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"center"}},[t._v("学院-2")]),t._v(" "),a("td",{staticStyle:{"text-align":"center"}},[t._v("院长-2")])])])]),t._v(" "),a("h2",{attrs:{id:"存储引擎"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#存储引擎"}},[t._v("#")]),t._v(" 存储引擎")]),t._v(" "),a("p",[t._v("Mysql 有多种存储引擎，"),a("strong",[t._v("不同的存储引擎保存数据和索引的方式是不同的，但表的定义则是在 Mysql 服务层统一处理的")]),t._v("。")]),t._v(" "),a("p",[t._v("简单列举几个存储引擎：")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("InnoDB")]),t._v(" - Mysql 的默认事务型存储引擎，并提供了行级锁和外键的约束。性能不错且支持自动故障恢复。")]),t._v(" "),a("li",[a("strong",[t._v("MyISAM")]),t._v(" - Mysql 5.1 版本前的默认存储引擎。特性丰富但不支持事务，也不支持行级锁和外键，也没有故障恢复功能。")]),t._v(" "),a("li",[a("strong",[t._v("CSV")]),t._v(" - 可以将 CSV 文件作为 Mysql 的表来处理，但这种表不支持索引。")]),t._v(" "),a("li",[a("strong",[t._v("MEMORY")]),t._v(" 。所有的数据都在内存中，数据的处理速度快，但是安全性不高。")])]),t._v(" "),a("h3",{attrs:{id:"innodb-vs-myisam"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#innodb-vs-myisam"}},[t._v("#")]),t._v(" InnoDB vs. MyISAM")]),t._v(" "),a("p",[t._v("InnoDB 和 MyISAM 是目前使用的最多的两种 Mysql 存储引擎。")]),t._v(" "),a("ul",[a("li",[t._v("数据结构比较：\n"),a("ul",[a("li",[t._v("InnoDB 和 MyISAM 的索引数据结构"),a("strong",[t._v("都是 B+ 树")]),t._v("。")]),t._v(" "),a("li",[t._v("MyIASM 的 B+ 树中存储的内容实际上是实际数据的地址值。也就是说它的索引和实际数据是分开的，"),a("strong",[t._v("只不过使用索引指向了实际数据。这种索引的模式被称为非聚集索引。")])]),t._v(" "),a("li",[t._v("InnoDB 的 B+ 树中存储的内容是实际的数据，这种索引有被称为聚集索引。")])])]),t._v(" "),a("li",[t._v("事务支持比较：\n"),a("ul",[a("li",[t._v("InnoDB 支持事务，并提供了行级锁和外键的约束。")]),t._v(" "),a("li",[t._v("MyIASM 不支持事务，也不支持行级锁和外键。")])])]),t._v(" "),a("li",[t._v("故障恢复比较：\n"),a("ul",[a("li",[t._v("InnoDB 支持故障恢复。")]),t._v(" "),a("li",[t._v("MyISAM 不支持故障恢复。")])])])]),t._v(" "),a("h2",{attrs:{id:"数据库比较"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#数据库比较"}},[t._v("#")]),t._v(" 数据库比较")]),t._v(" "),a("h3",{attrs:{id:"常见数据库比较"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#常见数据库比较"}},[t._v("#")]),t._v(" 常见数据库比较")]),t._v(" "),a("ul",[a("li",[a("code",[t._v("Oracle")]),t._v(" - 久负盛名的商业数据库。功能强大、稳定。最大的缺点就是费钱。")]),t._v(" "),a("li",[a("code",[t._v("Mysql")]),t._v(" - 曾经是互联网公司的最爱，但自动 Mysql 被 Oracle 公司收购后，好日子可能一去不复返。很多公司或开源项目已经逐渐寻找其他的开源产品来替代 Mysql。")]),t._v(" "),a("li",[a("code",[t._v("MariaDB")]),t._v(" - 开源关系型数据库。 MySQL 的真正开源的发行版本，由 Mysql 部分核心人员创建。可作为 Mysql 的替代产品。")]),t._v(" "),a("li",[a("code",[t._v("PostgreSQL")]),t._v(" - 开源关系型数据库。和 MySQL 的工作方式非常相似，社区支持做得很好。可作为 Mysql 的替代产品。")]),t._v(" "),a("li",[a("code",[t._v("SQLite")]),t._v(" - 开源的轻量级数据库，移动端常常使用。")]),t._v(" "),a("li",[a("code",[t._v("H2")]),t._v(" - 内存数据库，一般用作开发、测试环境数据库。")]),t._v(" "),a("li",[a("code",[t._v("SQL Server")]),t._v(" - 微软 Windows 生态系统的数据库。我想，Java 程序员应该没人用吧。")])]),t._v(" "),a("h3",{attrs:{id:"oracle-vs-mysql"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#oracle-vs-mysql"}},[t._v("#")]),t._v(" Oracle vs. Mysql")]),t._v(" "),a("p",[t._v("目前为止，Java 领域用的最多的关系型数据库，应该还是 Oracle 和 Mysql，所以这里做一下比较。")]),t._v(" "),a("h4",{attrs:{id:"数据库对象差异"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#数据库对象差异"}},[t._v("#")]),t._v(" 数据库对象差异")]),t._v(" "),a("p",[t._v("在 Mysql 中，"),a("strong",[t._v("一个用户可以创建多个库")]),t._v("。")]),t._v(" "),a("p",[t._v("而在 Oracle 中，Oracle 服务器是由两部分组成")]),t._v(" "),a("ul",[a("li",[t._v("数据库实例【理解为对象，看不见的】")]),t._v(" "),a("li",[t._v("数据库【理解为类，看得见的】")])]),t._v(" "),a("p",[a("strong",[t._v("一个数据库实例可拥有多个用户，一个用户默认拥有一个表空间。")])]),t._v(" "),a("p",[a("strong",[t._v("表空间是存储我们数据库表的地方，表空间内可以有多个文件。")])]),t._v(" "),a("h4",{attrs:{id:"sql-差异"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#sql-差异"}},[t._v("#")]),t._v(" SQL 差异")]),t._v(" "),a("p",[t._v("（1）主键递增")]),t._v(" "),a("p",[t._v("Mysql 可以设置 "),a("code",[t._v("AUTO_INCREMENT")]),t._v(" 约束来指定主键为自增序列。")]),t._v(" "),a("p",[t._v("Oracle 需要通过 "),a("code",[t._v("CREATE SEQUENCE")]),t._v(" 创建序列。")]),t._v(" "),a("p",[t._v("（2）分页查询")]),t._v(" "),a("p",[t._v("Mysql 分页基于 "),a("code",[t._v("SELECT ... FROM ... LIMIT ...")]),t._v(" 完成，较简单。")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("select")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("from")]),t._v(" help_category "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("order")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("by")]),t._v(" parent_category_id "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("limit")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("10")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("5")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),a("p",[t._v("Oracle 分页基于 "),a("code",[t._v("SELECT ... FROM (SELECT ROWNUM ...) WHERE ...")]),t._v(" 完成，较复杂。")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("select")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("from")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("select")]),t._v(" rownum rr"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("a"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("from")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("select")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("from")]),t._v(" emp "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("order")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("by")]),t._v(" sal"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" a "),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("where")]),t._v(" rr"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v(">")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("5")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("and")]),t._v(" rr"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("<=")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("10")]),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),a("h4",{attrs:{id:"事务差异"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#事务差异"}},[t._v("#")]),t._v(" 事务差异")]),t._v(" "),a("ul",[a("li",[t._v("auto commit\n"),a("ul",[a("li",[t._v("Mysql 事务是 autocommit 模式，即自动提交事务；")]),t._v(" "),a("li",[t._v("Oracle 事务需要手动 "),a("code",[t._v("COMMIT")]),t._v("。")])])]),t._v(" "),a("li",[t._v("事务隔离级别\n"),a("ul",[a("li",[t._v("Mysql 默认的事务隔离级别是可重复读（"),a("code",[t._v("REPEATABLE READ")]),t._v("）")]),t._v(" "),a("li",[t._v("Oracle 支持读已提交（"),a("code",[t._v("READ COMMITTED")]),t._v("）和串行化（"),a("code",[t._v("SERIALIZABLE")]),t._v("） 两种事务隔离级别，默认事务隔离级别是读已提交（"),a("code",[t._v("READ COMMITTED")]),t._v("）")])])])]),t._v(" "),a("h3",{attrs:{id:"数据类型比较"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#数据类型比较"}},[t._v("#")]),t._v(" 数据类型比较")]),t._v(" "),a("blockquote",[a("p",[t._v("不同数据库中，对数据类型的支持是不一样的。")]),t._v(" "),a("p",[t._v("即使存在同一种数据类型，也可能存在名称不同、或大小不同等问题。")]),t._v(" "),a("p",[t._v("因此，对于数据类型的支持详情必须参考各数据库的官方文档。")])]),t._v(" "),a("p",[t._v("下面列举一些常见数据类型对比：")]),t._v(" "),a("table",[a("thead",[a("tr",[a("th",{staticStyle:{"text-align":"left"}},[t._v("数据类型")]),t._v(" "),a("th",{staticStyle:{"text-align":"left"}},[t._v("Oracle")]),t._v(" "),a("th",{staticStyle:{"text-align":"left"}},[t._v("MySQL")]),t._v(" "),a("th",{staticStyle:{"text-align":"left"}},[t._v("PostgreSQL")])])]),t._v(" "),a("tbody",[a("tr",[a("td",{staticStyle:{"text-align":"left"}},[a("code",[t._v("boolean")])]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Byte")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("N/A")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Boolean")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"left"}},[a("code",[t._v("integer")])]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Number")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Int Integer")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Int Integer")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"left"}},[a("code",[t._v("float")])]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Number")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Float")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Numeric")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"left"}},[a("code",[t._v("currency")])]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("N/A")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("N/A")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Money")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"left"}},[a("code",[t._v("string (fixed)")])]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Char")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Char")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Char")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"left"}},[a("code",[t._v("string (variable)")])]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Varchar Varchar2")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Varchar")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Varchar")])]),t._v(" "),a("tr",[a("td",{staticStyle:{"text-align":"left"}},[a("code",[t._v("binary object")])]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Long Raw")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Blob Text")]),t._v(" "),a("td",{staticStyle:{"text-align":"left"}},[t._v("Binary Varbinary")])])])]),t._v(" "),a("blockquote",[a("p",[t._v("数据类型对比表摘自 "),a("a",{attrs:{href:"https://www.runoob.com/sql/sql-datatypes-general.html",target:"_blank",rel:"noopener noreferrer"}},[t._v("SQL 通用数据类型"),a("OutboundLink")],1),t._v("、"),a("a",{attrs:{href:"https://www.runoob.com/sql/sql-datatypes.html",target:"_blank",rel:"noopener noreferrer"}},[t._v("SQL 用于各种数据库的数据类型"),a("OutboundLink")],1)])]),t._v(" "),a("h2",{attrs:{id:"sql-faq"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#sql-faq"}},[t._v("#")]),t._v(" SQL FAQ")]),t._v(" "),a("h3",{attrs:{id:"select-count-、select-count-1-和-select-count-具体字段-性能有差别吗"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#select-count-、select-count-1-和-select-count-具体字段-性能有差别吗"}},[t._v("#")]),t._v(" SELECT COUNT(*)、SELECT COUNT(1) 和 SELECT COUNT(具体字段) 性能有差别吗？")]),t._v(" "),a("p",[t._v("在 MySQL InnoDB 存储引擎中，"),a("code",[t._v("COUNT(*)")]),t._v(" 和 "),a("code",[t._v("COUNT(1)")]),t._v(" 都是对所有结果进行 "),a("code",[t._v("COUNT")]),t._v("。因此"),a("code",[t._v("COUNT(*)")]),t._v("和"),a("code",[t._v("COUNT(1)")]),t._v("本质上并没有区别，执行的复杂度都是 "),a("code",[t._v("O(N)")]),t._v("，也就是采用全表扫描，进行循环 + 计数的方式进行统计。")]),t._v(" "),a("p",[t._v("如果是 MySQL MyISAM 存储引擎，统计数据表的行数只需要"),a("code",[t._v("O(1)")]),t._v("的复杂度，这是因为每张 MyISAM 的数据表都有一个 meta 信息存储了"),a("code",[t._v("row_count")]),t._v("值，而一致性则由表级锁来保证。因为 InnoDB 支持事务，采用行级锁和 MVCC 机制，所以无法像 MyISAM 一样，只维护一个"),a("code",[t._v("row_count")]),t._v("变量，因此需要采用扫描全表，进行循环 + 计数的方式来完成统计。")]),t._v(" "),a("p",[t._v("需要注意的是，在实际执行中，"),a("code",[t._v("COUNT(*)")]),t._v("和"),a("code",[t._v("COUNT(1)")]),t._v("的执行时间可能略有差别，不过你还是可以把它俩的执行效率看成是相等的。")]),t._v(" "),a("p",[t._v("另外在 InnoDB 引擎中，如果采用"),a("code",[t._v("COUNT(*)")]),t._v("和"),a("code",[t._v("COUNT(1)")]),t._v("来统计数据行数，要尽量采用二级索引。因为主键采用的索引是聚簇索引，聚簇索引包含的信息多，明显会大于二级索引（非聚簇索引）。对于"),a("code",[t._v("COUNT(*)")]),t._v("和"),a("code",[t._v("COUNT(1)")]),t._v("来说，它们不需要查找具体的行，只是统计行数，系统会自动采用占用空间更小的二级索引来进行统计。")]),t._v(" "),a("p",[t._v("然而如果想要查找具体的行，那么采用主键索引的效率更高。如果有多个二级索引，会使用 key_len 小的二级索引进行扫描。当没有二级索引的时候，才会采用主键索引来进行统计。")]),t._v(" "),a("p",[t._v("这里我总结一下：")]),t._v(" "),a("ol",[a("li",[t._v("一般情况下，三者执行的效率为 "),a("code",[t._v("COUNT(*)")]),t._v("= "),a("code",[t._v("COUNT(1)")]),t._v("> "),a("code",[t._v("COUNT(字段)")]),t._v("。我们尽量使用"),a("code",[t._v("COUNT(*)")]),t._v("，当然如果你要统计的是某个字段的非空数据行数，则另当别论，毕竟比较执行效率的前提是结果一样才可以。")]),t._v(" "),a("li",[t._v("如果要统计"),a("code",[t._v("COUNT(*)")]),t._v("，尽量在数据表上建立二级索引，系统会自动采用"),a("code",[t._v("key_len")]),t._v("小的二级索引进行扫描，这样当我们使用"),a("code",[t._v("SELECT COUNT(*)")]),t._v("的时候效率就会提升，有时候可以提升几倍甚至更高。")])]),t._v(" "),a("blockquote",[a("p",[t._v("——摘自"),a("a",{attrs:{href:"https://time.geekbang.org/column/intro/192",target:"_blank",rel:"noopener noreferrer"}},[t._v("极客时间 - SQL 必知必会"),a("OutboundLink")],1)])]),t._v(" "),a("h3",{attrs:{id:"order-by-是对分的组排序还是对分组中的记录排序呢"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#order-by-是对分的组排序还是对分组中的记录排序呢"}},[t._v("#")]),t._v(" ORDER BY 是对分的组排序还是对分组中的记录排序呢？")]),t._v(" "),a("p",[t._v("ORDER BY 就是对记录进行排序。如果你在 ORDER BY 前面用到了 GROUP BY，实际上这是一种分组的聚合方式，已经把一组的数据聚合成为了一条记录，再进行排序的时候，相当于对分的组进行了排序。")]),t._v(" "),a("h3",{attrs:{id:"select-语句内部的执行步骤"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#select-语句内部的执行步骤"}},[t._v("#")]),t._v(" SELECT 语句内部的执行步骤")]),t._v(" "),a("p",[t._v("一条完整的 SELECT 语句内部的执行顺序是这样的：")]),t._v(" "),a("ol",[a("li",[t._v("FROM 子句组装数据（包括通过 ON 进行连接）；")]),t._v(" "),a("li",[t._v("WHERE 子句进行条件筛选；")]),t._v(" "),a("li",[t._v("GROUP BY 分组 ；")]),t._v(" "),a("li",[t._v("使用聚集函数进行计算；")]),t._v(" "),a("li",[t._v("HAVING 筛选分组；")]),t._v(" "),a("li",[t._v("计算所有的表达式；")]),t._v(" "),a("li",[t._v("SELECT 的字段；")]),t._v(" "),a("li",[t._v("ORDER BY 排序；")]),t._v(" "),a("li",[t._v("LIMIT 筛选。")])]),t._v(" "),a("blockquote",[a("p",[t._v("——摘自"),a("a",{attrs:{href:"https://time.geekbang.org/column/intro/192",target:"_blank",rel:"noopener noreferrer"}},[t._v("极客时间 - SQL 必知必会"),a("OutboundLink")],1)])]),t._v(" "),a("h3",{attrs:{id:"解哪种情况下应该使用-exists-哪种情况应该用-in"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#解哪种情况下应该使用-exists-哪种情况应该用-in"}},[t._v("#")]),t._v(" 解哪种情况下应该使用 EXISTS，哪种情况应该用 IN")]),t._v(" "),a("p",[t._v("索引是个前提，其实选择与否还是要看表的大小。你可以将选择的标准理解为小表驱动大表。在这种方式下效率是最高的。")]),t._v(" "),a("p",[t._v("比如下面这样：")]),t._v(" "),a("div",{staticClass:"language- extra-class"},[a("pre",{pre:!0,attrs:{class:"language-text"}},[a("code",[t._v(" SELECT * FROM A WHERE cc IN (SELECT cc FROM B)\n SELECT * FROM A WHERE EXISTS (SELECT cc FROM B WHERE B.cc=A.cc)\n")])])]),a("p",[t._v("当 A 小于 B 时，用 EXISTS。因为 EXISTS 的实现，相当于外表循环，实现的逻辑类似于：")]),t._v(" "),a("div",{staticClass:"language- extra-class"},[a("pre",{pre:!0,attrs:{class:"language-text"}},[a("code",[t._v(" for i in A\n for j in B\n if j.cc == i.cc then ...\n")])])]),a("p",[t._v("当 B 小于 A 时用 IN，因为实现的逻辑类似于：")]),t._v(" "),a("div",{staticClass:"language- extra-class"},[a("pre",{pre:!0,attrs:{class:"language-text"}},[a("code",[t._v(" for i in B\n for j in A\n if j.cc == i.cc then ...\n")])])]),a("p",[t._v("哪个表小就用哪个表来驱动，A 表小就用 EXISTS，B 表小就用 IN。")]),t._v(" "),a("blockquote",[a("p",[t._v("——摘自"),a("a",{attrs:{href:"https://time.geekbang.org/column/intro/192",target:"_blank",rel:"noopener noreferrer"}},[t._v("极客时间 - SQL 必知必会"),a("OutboundLink")],1)])]),t._v(" "),a("h2",{attrs:{id:"参考资料"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#参考资料"}},[t._v("#")]),t._v(" 参考资料")]),t._v(" "),a("ul",[a("li",[a("a",{attrs:{href:"https://juejin.im/post/5a9ca0d6518825555c1d1acd",target:"_blank",rel:"noopener noreferrer"}},[t._v("数据库面试题(开发者必看)"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"https://github.com/CyC2018/Interview-Notebook/blob/master/notes/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%B3%BB%E7%BB%9F%E5%8E%9F%E7%90%86.md",target:"_blank",rel:"noopener noreferrer"}},[t._v("数据库系统原理"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"https://juejin.im/post/5b55b842f265da0f9e589e79",target:"_blank",rel:"noopener noreferrer"}},[t._v("数据库两大神器【索引和锁】"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"https://www.jianshu.com/p/32b3e91aa22c",target:"_blank",rel:"noopener noreferrer"}},[t._v("分库分表需要考虑的问题及方案"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"https://blog.csdn.net/bluishglc/article/details/7710738",target:"_blank",rel:"noopener noreferrer"}},[t._v("数据库分库分表(sharding)系列(二) 全局主键生成策略"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"https://blog.csdn.net/bluishglc/article/details/7970268",target:"_blank",rel:"noopener noreferrer"}},[t._v("一种支持自由规划无须数据迁移和修改路由代码的 Sharding 扩容方案"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"https://shardingsphere.apache.org/document/current/cn/features/transaction/",target:"_blank",rel:"noopener noreferrer"}},[t._v("ShardingSphere 分布式事务"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"https://zhuanlan.zhihu.com/p/39651803",target:"_blank",rel:"noopener noreferrer"}},[t._v("mysql 和 oracle 的区别"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"https://www.runoob.com/sql/sql-tutorial.html",target:"_blank",rel:"noopener noreferrer"}},[t._v("RUNOOB SQL 教程"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"https://gameinstitute.qq.com/community/detail/107154",target:"_blank",rel:"noopener noreferrer"}},[t._v("如果有人问你数据库的原理，叫他看这篇文章"),a("OutboundLink")],1)])])])}),[],!1,null,null,null);a.default=v.exports}}]); \ No newline at end of file diff --git a/assets/js/13.a61047c2.js b/assets/js/13.a61047c2.js new file mode 100644 index 00000000..bded4577 --- /dev/null +++ b/assets/js/13.a61047c2.js @@ -0,0 +1 @@ +(window.webpackJsonp=window.webpackJsonp||[]).push([[13],{350:function(s,t,a){"use strict";a.r(t);var e=a(4),r=Object(e.a)({},(function(){var s=this,t=s._self._c;return t("ContentSlotsDistributor",{attrs:{"slot-key":s.$parent.slotKey}},[t("h1",{attrs:{id:"sql-语法基础特性"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#sql-语法基础特性"}},[s._v("#")]),s._v(" SQL 语法基础特性")]),s._v(" "),t("blockquote",[t("p",[s._v("本文针对关系型数据库的基本语法。限于篇幅，本文侧重说明用法，不会展开讲解特性、原理。")]),s._v(" "),t("p",[s._v("本文语法主要针对 Mysql，但大部分的语法对其他关系型数据库也适用。")])]),s._v(" "),t("p",[t("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/snap/20200115160512.png",alt:"img"}})]),s._v(" "),t("h2",{attrs:{id:"sql-简介"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#sql-简介"}},[s._v("#")]),s._v(" SQL 简介")]),s._v(" "),t("h3",{attrs:{id:"数据库术语"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#数据库术语"}},[s._v("#")]),s._v(" 数据库术语")]),s._v(" "),t("ul",[t("li",[t("code",[s._v("数据库（database）")]),s._v(" - 保存有组织的数据的容器（通常是一个文件或一组文件）。")]),s._v(" "),t("li",[t("code",[s._v("数据表（table）")]),s._v(" - 某种特定类型数据的结构化清单。")]),s._v(" "),t("li",[t("code",[s._v("模式（schema）")]),s._v(" - 关于数据库和表的布局及特性的信息。模式定义了数据在表中如何存储，包含存储什么样的数据，数据如何分解，各部分信息如何命名等信息。数据库和表都有模式。")]),s._v(" "),t("li",[t("code",[s._v("列（column）")]),s._v(" - 表中的一个字段。所有表都是由一个或多个列组成的。")]),s._v(" "),t("li",[t("code",[s._v("行（row）")]),s._v(" - 表中的一个记录。")]),s._v(" "),t("li",[t("code",[s._v("主键（primary key）")]),s._v(" - 一列（或一组列），其值能够唯一标识表中每一行。")])]),s._v(" "),t("h3",{attrs:{id:"sql-语法"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#sql-语法"}},[s._v("#")]),s._v(" SQL 语法")]),s._v(" "),t("blockquote",[t("p",[s._v("SQL（Structured Query Language)，标准 SQL 由 ANSI 标准委员会管理，从而称为 ANSI SQL。各个 DBMS 都有自己的实现，如 PL/SQL、Transact-SQL 等。")])]),s._v(" "),t("h4",{attrs:{id:"sql-语法结构"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#sql-语法结构"}},[s._v("#")]),s._v(" SQL 语法结构")]),s._v(" "),t("p",[t("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/master/cs/database/mysql/sql-syntax.png",alt:"img"}})]),s._v(" "),t("p",[s._v("SQL 语法结构包括：")]),s._v(" "),t("ul",[t("li",[t("strong",[t("code",[s._v("子句")])]),s._v(" - 是语句和查询的组成成分。（在某些情况下，这些都是可选的。）")]),s._v(" "),t("li",[t("strong",[t("code",[s._v("表达式")])]),s._v(" - 可以产生任何标量值，或由列和行的数据库表")]),s._v(" "),t("li",[t("strong",[t("code",[s._v("谓词")])]),s._v(" - 给需要评估的 SQL 三值逻辑（3VL）（true/false/unknown）或布尔真值指定条件，并限制语句和查询的效果，或改变程序流程。")]),s._v(" "),t("li",[t("strong",[t("code",[s._v("查询")])]),s._v(" - 基于特定条件检索数据。这是 SQL 的一个重要组成部分。")]),s._v(" "),t("li",[t("strong",[t("code",[s._v("语句")])]),s._v(" - 可以持久地影响纲要和数据，也可以控制数据库事务、程序流程、连接、会话或诊断。")])]),s._v(" "),t("h4",{attrs:{id:"sql-语法要点"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#sql-语法要点"}},[s._v("#")]),s._v(" SQL 语法要点")]),s._v(" "),t("ul",[t("li",[t("strong",[s._v("SQL 语句不区分大小写")]),s._v("，但是数据库表名、列名和值是否区分，依赖于具体的 DBMS 以及配置。")])]),s._v(" "),t("p",[s._v("例如："),t("code",[s._v("SELECT")]),s._v(" 与 "),t("code",[s._v("select")]),s._v(" 、"),t("code",[s._v("Select")]),s._v(" 是相同的。")]),s._v(" "),t("ul",[t("li",[t("p",[t("strong",[s._v("多条 SQL 语句必须以分号（"),t("code",[s._v(";")]),s._v("）分隔")]),s._v("。")])]),s._v(" "),t("li",[t("p",[s._v("处理 SQL 语句时，"),t("strong",[s._v("所有空格都被忽略")]),s._v("。SQL 语句可以写成一行，也可以分写为多行。")])])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token comment"}},[s._v("-- 一行 SQL 语句")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("UPDATE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SET")]),s._v(" username"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'robot'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" password"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'robot'")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" username "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'root'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n\n"),t("span",{pre:!0,attrs:{class:"token comment"}},[s._v("-- 多行 SQL 语句")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("UPDATE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SET")]),s._v(" username"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'robot'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" password"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'robot'")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" username "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'root'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("ul",[t("li",[s._v("SQL 支持三种注释")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token comment"}},[s._v("## 注释1")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token comment"}},[s._v("-- 注释2")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token comment"}},[s._v("/* 注释3 */")]),s._v("\n")])])]),t("h4",{attrs:{id:"sql-分类"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#sql-分类"}},[s._v("#")]),s._v(" SQL 分类")]),s._v(" "),t("h4",{attrs:{id:"数据定义语言-ddl"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#数据定义语言-ddl"}},[s._v("#")]),s._v(" 数据定义语言（DDL）")]),s._v(" "),t("p",[s._v("数据定义语言（Data Definition Language，DDL）是 SQL 语言集中负责数据结构定义与数据库对象定义的语言。")]),s._v(" "),t("p",[s._v("DDL 的主要功能是"),t("strong",[s._v("定义数据库对象")]),s._v("。")]),s._v(" "),t("p",[s._v("DDL 的核心指令是 "),t("code",[s._v("CREATE")]),s._v("、"),t("code",[s._v("ALTER")]),s._v("、"),t("code",[s._v("DROP")]),s._v("。")]),s._v(" "),t("h4",{attrs:{id:"数据操纵语言-dml"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#数据操纵语言-dml"}},[s._v("#")]),s._v(" 数据操纵语言（DML）")]),s._v(" "),t("p",[s._v("数据操纵语言（Data Manipulation Language, DML）是用于数据库操作，对数据库其中的对象和数据运行访问工作的编程语句。")]),s._v(" "),t("p",[s._v("DML 的主要功能是 "),t("strong",[s._v("访问数据")]),s._v("，因此其语法都是以"),t("strong",[s._v("读写数据库")]),s._v("为主。")]),s._v(" "),t("p",[s._v("DML 的核心指令是 "),t("code",[s._v("INSERT")]),s._v("、"),t("code",[s._v("UPDATE")]),s._v("、"),t("code",[s._v("DELETE")]),s._v("、"),t("code",[s._v("SELECT")]),s._v("。这四个指令合称 CRUD(Create, Read, Update, Delete)，即增删改查。")]),s._v(" "),t("h4",{attrs:{id:"事务控制语言-tcl"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#事务控制语言-tcl"}},[s._v("#")]),s._v(" 事务控制语言（TCL）")]),s._v(" "),t("p",[s._v("事务控制语言 (Transaction Control Language, TCL) 用于"),t("strong",[s._v("管理数据库中的事务")]),s._v("。这些用于管理由 DML 语句所做的更改。它还允许将语句分组为逻辑事务。")]),s._v(" "),t("p",[s._v("TCL 的核心指令是 "),t("code",[s._v("COMMIT")]),s._v("、"),t("code",[s._v("ROLLBACK")]),s._v("。")]),s._v(" "),t("h4",{attrs:{id:"数据控制语言-dcl"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#数据控制语言-dcl"}},[s._v("#")]),s._v(" 数据控制语言（DCL）")]),s._v(" "),t("p",[s._v("数据控制语言 (Data Control Language, DCL) 是一种可对数据访问权进行控制的指令，它可以控制特定用户账户对数据表、查看表、预存程序、用户自定义函数等数据库对象的控制权。")]),s._v(" "),t("p",[s._v("DCL 的核心指令是 "),t("code",[s._v("GRANT")]),s._v("、"),t("code",[s._v("REVOKE")]),s._v("。")]),s._v(" "),t("p",[s._v("DCL 以"),t("strong",[s._v("控制用户的访问权限")]),s._v("为主，因此其指令作法并不复杂，可利用 DCL 控制的权限有："),t("code",[s._v("CONNECT")]),s._v("、"),t("code",[s._v("SELECT")]),s._v("、"),t("code",[s._v("INSERT")]),s._v("、"),t("code",[s._v("UPDATE")]),s._v("、"),t("code",[s._v("DELETE")]),s._v("、"),t("code",[s._v("EXECUTE")]),s._v("、"),t("code",[s._v("USAGE")]),s._v("、"),t("code",[s._v("REFERENCES")]),s._v("。")]),s._v(" "),t("p",[s._v("根据不同的 DBMS 以及不同的安全性实体，其支持的权限控制也有所不同。")]),s._v(" "),t("hr"),s._v(" "),t("p",[t("strong",[s._v("（以下为 DML 语句用法）")])]),s._v(" "),t("h2",{attrs:{id:"增删改查-crud"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#增删改查-crud"}},[s._v("#")]),s._v(" 增删改查（CRUD）")]),s._v(" "),t("p",[s._v("增删改查，又称为 "),t("strong",[t("code",[s._v("CRUD")])]),s._v("，是数据库基本操作中的基本操作。")]),s._v(" "),t("h3",{attrs:{id:"插入数据"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#插入数据"}},[s._v("#")]),s._v(" 插入数据")]),s._v(" "),t("blockquote",[t("ul",[t("li",[t("code",[s._v("INSERT INTO")]),s._v(" 语句用于向表中插入新记录。")])])]),s._v(" "),t("h4",{attrs:{id:"插入完整的行"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#插入完整的行"}},[s._v("#")]),s._v(" 插入完整的行")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INSERT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INTO")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("VALUES")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("10")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'root'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'root'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'xxxx@163.com'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"插入行的一部分"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#插入行的一部分"}},[s._v("#")]),s._v(" 插入行的一部分")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INSERT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INTO")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("username"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" password"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" email"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("VALUES")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'admin'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'admin'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'xxxx@163.com'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"插入查询出来的数据"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#插入查询出来的数据"}},[s._v("#")]),s._v(" 插入查询出来的数据")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INSERT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INTO")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("username"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" name\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" account"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"更新数据"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#更新数据"}},[s._v("#")]),s._v(" 更新数据")]),s._v(" "),t("blockquote",[t("ul",[t("li",[t("code",[s._v("UPDATE")]),s._v(" 语句用于更新表中的记录。")])])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("UPDATE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SET")]),s._v(" username"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'robot'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" password"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'robot'")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" username "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'root'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"删除数据"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#删除数据"}},[s._v("#")]),s._v(" 删除数据")]),s._v(" "),t("blockquote",[t("ul",[t("li",[t("code",[s._v("DELETE")]),s._v(" 语句用于删除表中的记录。")]),s._v(" "),t("li",[t("code",[s._v("TRUNCATE TABLE")]),s._v(" 可以清空表，也就是删除所有行。")])])]),s._v(" "),t("h4",{attrs:{id:"删除表中的指定数据"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#删除表中的指定数据"}},[s._v("#")]),s._v(" 删除表中的指定数据")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DELETE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" username "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'robot'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"清空表中的数据"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#清空表中的数据"}},[s._v("#")]),s._v(" 清空表中的数据")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TRUNCATE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"查询数据"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#查询数据"}},[s._v("#")]),s._v(" 查询数据")]),s._v(" "),t("blockquote",[t("ul",[t("li",[t("code",[s._v("SELECT")]),s._v(" 语句用于从数据库中查询数据。")]),s._v(" "),t("li",[t("code",[s._v("DISTINCT")]),s._v(" 用于返回唯一不同的值。它作用于所有列，也就是说所有列的值都相同才算相同。")]),s._v(" "),t("li",[t("code",[s._v("LIMIT")]),s._v(" 限制返回的行数。可以有两个参数，第一个参数为起始行，从 0 开始；第二个参数为返回的总行数。\n"),t("ul",[t("li",[t("code",[s._v("ASC")]),s._v(" ：升序（默认）")]),s._v(" "),t("li",[t("code",[s._v("DESC")]),s._v(" ：降序")])])])])]),s._v(" "),t("h4",{attrs:{id:"查询单列"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#查询单列"}},[s._v("#")]),s._v(" 查询单列")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" prod_name "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"查询多列"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#查询多列"}},[s._v("#")]),s._v(" 查询多列")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" prod_id"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" prod_name"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" prod_price "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"查询所有列"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#查询所有列"}},[s._v("#")]),s._v(" 查询所有列")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"查询不同的值"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#查询不同的值"}},[s._v("#")]),s._v(" 查询不同的值")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DISTINCT")]),s._v(" vend_id "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"限制查询数量"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#限制查询数量"}},[s._v("#")]),s._v(" 限制查询数量")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token comment"}},[s._v("-- 返回前 5 行")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("LIMIT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("5")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("LIMIT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("0")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("5")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token comment"}},[s._v("-- 返回第 3 ~ 5 行")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("LIMIT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("2")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("3")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h2",{attrs:{id:"过滤数据-where"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#过滤数据-where"}},[s._v("#")]),s._v(" 过滤数据（WHERE）")]),s._v(" "),t("p",[s._v("子查询是嵌套在较大查询中的 SQL 查询。子查询也称为"),t("strong",[s._v("内部查询")]),s._v("或"),t("strong",[s._v("内部选择")]),s._v("，而包含子查询的语句也称为"),t("strong",[s._v("外部查询")]),s._v("或"),t("strong",[s._v("外部选择")]),s._v("。")]),s._v(" "),t("ul",[t("li",[t("p",[s._v("子查询可以嵌套在 "),t("code",[s._v("SELECT")]),s._v("，"),t("code",[s._v("INSERT")]),s._v("，"),t("code",[s._v("UPDATE")]),s._v(" 或 "),t("code",[s._v("DELETE")]),s._v(" 语句内或另一个子查询中。")])]),s._v(" "),t("li",[t("p",[s._v("子查询通常会在另一个 "),t("code",[s._v("SELECT")]),s._v(" 语句的 "),t("code",[s._v("WHERE")]),s._v(" 子句中添加。")])]),s._v(" "),t("li",[t("p",[s._v("您可以使用比较运算符，如 "),t("code",[s._v(">")]),s._v("，"),t("code",[s._v("<")]),s._v("，或 "),t("code",[s._v("=")]),s._v("。比较运算符也可以是多行运算符，如 "),t("code",[s._v("IN")]),s._v("，"),t("code",[s._v("ANY")]),s._v(" 或 "),t("code",[s._v("ALL")]),s._v("。")])]),s._v(" "),t("li",[t("p",[s._v("子查询必须被圆括号 "),t("code",[s._v("()")]),s._v(" 括起来。")])]),s._v(" "),t("li",[t("p",[s._v("内部查询首先在其父查询之前执行，以便可以将内部查询的结果传递给外部查询。执行过程可以参考下图：")]),s._v(" "),t("p",{attrs:{align:"center"}},[t("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/mysql/sql-subqueries.gif",alt:"sql-subqueries"}})])])]),s._v(" "),t("p",[t("strong",[s._v("子查询的子查询")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" cust_name"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" cust_contact\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" customers\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" cust_id "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("IN")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" cust_id\n "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" orders\n "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" order_num "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("IN")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" order_num\n "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" orderitems\n "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" prod_id "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'RGAN01'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"where-子句"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#where-子句"}},[s._v("#")]),s._v(" WHERE 子句")]),s._v(" "),t("p",[s._v("在 SQL 语句中，数据根据 "),t("code",[s._v("WHERE")]),s._v(" 子句中指定的搜索条件进行过滤。")]),s._v(" "),t("p",[t("code",[s._v("WHERE")]),s._v(" 子句的基本格式如下：")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" ……"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("列名"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" ……"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("表名"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" ……"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("子句条件"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v("\n")])])]),t("p",[t("code",[s._v("WHERE")]),s._v(" 子句用于过滤记录，即缩小访问数据的范围。"),t("code",[s._v("WHERE")]),s._v(" 后跟一个返回 "),t("code",[s._v("true")]),s._v(" 或 "),t("code",[s._v("false")]),s._v(" 的条件。")]),s._v(" "),t("p",[t("code",[s._v("WHERE")]),s._v(" 可以与 "),t("code",[s._v("SELECT")]),s._v("，"),t("code",[s._v("UPDATE")]),s._v(" 和 "),t("code",[s._v("DELETE")]),s._v(" 一起使用。")]),s._v(" "),t("p",[t("strong",[t("code",[s._v("SELECT")]),s._v(" 语句中的 "),t("code",[s._v("WHERE")]),s._v(" 子句")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" Customers\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" cust_name "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'Kids Place'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("p",[t("strong",[t("code",[s._v("UPDATE")]),s._v(" 语句中的 "),t("code",[s._v("WHERE")]),s._v(" 子句")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("UPDATE")]),s._v(" Customers\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SET")]),s._v(" cust_name "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'Jack Jones'")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" cust_name "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'Kids Place'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("p",[t("strong",[t("code",[s._v("DELETE")]),s._v(" 语句中的 "),t("code",[s._v("WHERE")]),s._v(" 子句")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DELETE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" Customers\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" cust_name "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'Kids Place'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("p",[s._v("可以在 "),t("code",[s._v("WHERE")]),s._v(" 子句中使用的操作符：")]),s._v(" "),t("h3",{attrs:{id:"比较操作符"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#比较操作符"}},[s._v("#")]),s._v(" 比较操作符")]),s._v(" "),t("table",[t("thead",[t("tr",[t("th",[s._v("运算符")]),s._v(" "),t("th",[s._v("描述")])])]),s._v(" "),t("tbody",[t("tr",[t("td",[t("code",[s._v("=")])]),s._v(" "),t("td",[s._v("等于")])]),s._v(" "),t("tr",[t("td",[t("code",[s._v("<>")])]),s._v(" "),t("td",[s._v("不等于。注释：在 SQL 的一些版本中，该操作符可被写成 !=")])]),s._v(" "),t("tr",[t("td",[t("code",[s._v(">")])]),s._v(" "),t("td",[s._v("大于")])]),s._v(" "),t("tr",[t("td",[t("code",[s._v("<")])]),s._v(" "),t("td",[s._v("小于")])]),s._v(" "),t("tr",[t("td",[t("code",[s._v(">=")])]),s._v(" "),t("td",[s._v("大于等于")])]),s._v(" "),t("tr",[t("td",[t("code",[s._v("<=")])]),s._v(" "),t("td",[s._v("小于等于")])])])]),s._v(" "),t("h3",{attrs:{id:"范围操作符"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#范围操作符"}},[s._v("#")]),s._v(" 范围操作符")]),s._v(" "),t("table",[t("thead",[t("tr",[t("th",[s._v("运算符")]),s._v(" "),t("th",[s._v("描述")])])]),s._v(" "),t("tbody",[t("tr",[t("td",[t("code",[s._v("BETWEEN")])]),s._v(" "),t("td",[s._v("在某个范围内")])]),s._v(" "),t("tr",[t("td",[t("code",[s._v("IN")])]),s._v(" "),t("td",[s._v("指定针对某个列的多个可能值")])])])]),s._v(" "),t("ul",[t("li",[t("p",[t("code",[s._v("IN")]),s._v(" 操作符在 "),t("code",[s._v("WHERE")]),s._v(" 子句中使用，作用是在指定的几个特定值中任选一个值。")])]),s._v(" "),t("li",[t("p",[t("code",[s._v("BETWEEN")]),s._v(" 操作符在 "),t("code",[s._v("WHERE")]),s._v(" 子句中使用，作用是选取介于某个范围内的值。")])])]),s._v(" "),t("p",[t("strong",[s._v("IN 示例")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" vend_id "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("IN")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'DLL01'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'BRS01'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("p",[t("strong",[s._v("BETWEEN 示例")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" prod_price "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("BETWEEN")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("3")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("AND")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("5")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"逻辑操作符"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#逻辑操作符"}},[s._v("#")]),s._v(" 逻辑操作符")]),s._v(" "),t("table",[t("thead",[t("tr",[t("th",[s._v("运算符")]),s._v(" "),t("th",[s._v("描述")])])]),s._v(" "),t("tbody",[t("tr",[t("td",[t("code",[s._v("AND")])]),s._v(" "),t("td",[s._v("并且（与）")])]),s._v(" "),t("tr",[t("td",[t("code",[s._v("OR")])]),s._v(" "),t("td",[s._v("或者（或）")])]),s._v(" "),t("tr",[t("td",[t("code",[s._v("NOT")])]),s._v(" "),t("td",[s._v("否定（非）")])])])]),s._v(" "),t("p",[t("code",[s._v("AND")]),s._v("、"),t("code",[s._v("OR")]),s._v("、"),t("code",[s._v("NOT")]),s._v(" 是用于对过滤条件的逻辑处理指令。")]),s._v(" "),t("ul",[t("li",[t("p",[t("code",[s._v("AND")]),s._v(" 优先级高于 "),t("code",[s._v("OR")]),s._v("，为了明确处理顺序，可以使用 "),t("code",[s._v("()")]),s._v("。"),t("code",[s._v("AND")]),s._v(" 操作符表示左右条件都要满足。")])]),s._v(" "),t("li",[t("p",[t("code",[s._v("OR")]),s._v(" 操作符表示左右条件满足任意一个即可。")])]),s._v(" "),t("li",[t("p",[t("code",[s._v("NOT")]),s._v(" 操作符用于否定一个条件。")])])]),s._v(" "),t("p",[t("strong",[s._v("AND 示例")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" prod_id"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" prod_name"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" prod_price\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" vend_id "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'DLL01'")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("AND")]),s._v(" prod_price "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("<=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("4")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("p",[t("strong",[s._v("OR 示例")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" prod_id"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" prod_name"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" prod_price\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" vend_id "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'DLL01'")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("OR")]),s._v(" vend_id "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'BRS01'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("p",[t("strong",[s._v("NOT 示例")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" prod_price "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("NOT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("BETWEEN")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("3")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("AND")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("5")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"通配符"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#通配符"}},[s._v("#")]),s._v(" 通配符")]),s._v(" "),t("table",[t("thead",[t("tr",[t("th",[s._v("运算符")]),s._v(" "),t("th",[s._v("描述")])])]),s._v(" "),t("tbody",[t("tr",[t("td",[t("code",[s._v("LIKE")])]),s._v(" "),t("td",[s._v("搜索某种模式")])]),s._v(" "),t("tr",[t("td",[t("code",[s._v("%")])]),s._v(" "),t("td",[s._v("表示任意字符出现任意次数")])]),s._v(" "),t("tr",[t("td",[t("code",[s._v("_")])]),s._v(" "),t("td",[s._v("表示任意字符出现一次")])]),s._v(" "),t("tr",[t("td",[t("code",[s._v("[]")])]),s._v(" "),t("td",[s._v("必须匹配指定位置的一个字符")])])])]),s._v(" "),t("p",[t("code",[s._v("LIKE")]),s._v(" 操作符在 "),t("code",[s._v("WHERE")]),s._v(" 子句中使用，作用是确定字符串是否匹配模式。只有字段是文本值时才使用 "),t("code",[s._v("LIKE")]),s._v("。")]),s._v(" "),t("p",[t("code",[s._v("LIKE")]),s._v(" 支持以下通配符匹配选项：")]),s._v(" "),t("ul",[t("li",[t("code",[s._v("%")]),s._v(" 表示任何字符出现任意次数。")]),s._v(" "),t("li",[t("code",[s._v("_")]),s._v(" 表示任何字符出现一次。")]),s._v(" "),t("li",[t("code",[s._v("[]")]),s._v(" 必须匹配指定位置的一个字符。")])]),s._v(" "),t("blockquote",[t("p",[s._v("注意："),t("strong",[s._v("不要滥用通配符，通配符位于开头处匹配会非常慢")]),s._v("。")])]),s._v(" "),t("p",[t("code",[s._v("%")]),s._v(" 示例：")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" prod_id"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" prod_name"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" prod_price\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" prod_name "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("LIKE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'%bean bag%'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("p",[t("code",[s._v("_")]),s._v(" 示例：")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" prod_id"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" prod_name"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" prod_price\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" prod_name "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("LIKE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'__ inch teddy bear'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("ul",[t("li")]),s._v(" "),t("h2",{attrs:{id:"排序-order-by"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#排序-order-by"}},[s._v("#")]),s._v(" 排序（ORDER BY）")]),s._v(" "),t("blockquote",[t("p",[t("code",[s._v("ORDER BY")]),s._v(" 用于对结果集进行排序。")])]),s._v(" "),t("p",[t("code",[s._v("ORDER BY")]),s._v(" 有两种排序模式：")]),s._v(" "),t("ul",[t("li",[t("code",[s._v("ASC")]),s._v(" ：升序（默认）")]),s._v(" "),t("li",[t("code",[s._v("DESC")]),s._v(" ：降序")])]),s._v(" "),t("p",[s._v("可以按多个列进行排序，并且为每个列指定不同的排序方式。")]),s._v(" "),t("p",[s._v("指定多个列的排序示例：")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" products\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ORDER")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("BY")]),s._v(" prod_price "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DESC")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" prod_name "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ASC")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h2",{attrs:{id:"数据定义-create、alter、drop"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#数据定义-create、alter、drop"}},[s._v("#")]),s._v(" 数据定义（CREATE、ALTER、DROP）")]),s._v(" "),t("blockquote",[t("p",[s._v("DDL 的主要功能是定义数据库对象（如：数据库、数据表、视图、索引等）。")])]),s._v(" "),t("h3",{attrs:{id:"数据库-database"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#数据库-database"}},[s._v("#")]),s._v(" 数据库（DATABASE）")]),s._v(" "),t("h4",{attrs:{id:"创建数据库"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#创建数据库"}},[s._v("#")]),s._v(" 创建数据库")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("CREATE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DATABASE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("IF")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("NOT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("EXISTS")]),s._v(" db_tutorial"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"删除数据库"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#删除数据库"}},[s._v("#")]),s._v(" 删除数据库")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DROP")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DATABASE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("IF")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("EXISTS")]),s._v(" db_tutorial"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"选择数据库"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#选择数据库"}},[s._v("#")]),s._v(" 选择数据库")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("USE")]),s._v(" db_tutorial"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"数据表-table"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#数据表-table"}},[s._v("#")]),s._v(" 数据表（TABLE）")]),s._v(" "),t("h4",{attrs:{id:"删除数据表"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#删除数据表"}},[s._v("#")]),s._v(" 删除数据表")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DROP")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("IF")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("EXISTS")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DROP")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("IF")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("EXISTS")]),s._v(" vip_user"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"创建数据表"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#创建数据表"}},[s._v("#")]),s._v(" 创建数据表")]),s._v(" "),t("p",[t("strong",[s._v("普通创建")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("CREATE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("\n id "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INT")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("10")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("UNSIGNED")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("NOT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COMMENT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'Id'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v("\n username "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("VARCHAR")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("64")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("NOT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DEFAULT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'default'")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COMMENT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'用户名'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v("\n password "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("VARCHAR")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("64")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("NOT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DEFAULT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'default'")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COMMENT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'密码'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v("\n email "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("VARCHAR")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("64")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("NOT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DEFAULT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'default'")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COMMENT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'邮箱'")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COMMENT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'用户表'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("p",[t("strong",[s._v("根据已有的表创建新表")])]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("CREATE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" vip_user "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("AS")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"修改数据表"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#修改数据表"}},[s._v("#")]),s._v(" 修改数据表")]),s._v(" "),t("h5",{attrs:{id:"添加列"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#添加列"}},[s._v("#")]),s._v(" 添加列")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ALTER")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ADD")]),s._v(" age "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("int")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("3")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h5",{attrs:{id:"删除列"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#删除列"}},[s._v("#")]),s._v(" 删除列")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ALTER")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DROP")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COLUMN")]),s._v(" age"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h5",{attrs:{id:"修改列"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#修改列"}},[s._v("#")]),s._v(" 修改列")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ALTER")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token identifier"}},[t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("`")]),s._v("user"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("`")])]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("MODIFY")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COLUMN")]),s._v(" age "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("tinyint")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"视图-view"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#视图-view"}},[s._v("#")]),s._v(" 视图（VIEW）")]),s._v(" "),t("blockquote",[t("p",[s._v("视图是基于 SQL 语句的结果集的可视化的表。"),t("strong",[s._v("视图是虚拟的表，本身不存储数据，也就不能对其进行索引操作")]),s._v("。对视图的操作和对普通表的操作一样。")])]),s._v(" "),t("p",[s._v("视图的作用：")]),s._v(" "),t("ul",[t("li",[s._v("简化复杂的 SQL 操作，比如复杂的连接。")]),s._v(" "),t("li",[s._v("只使用实际表的一部分数据。")]),s._v(" "),t("li",[s._v("通过只给用户访问视图的权限，保证数据的安全性。")]),s._v(" "),t("li",[s._v("更改数据格式和表示。")])]),s._v(" "),t("h4",{attrs:{id:"创建视图"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#创建视图"}},[s._v("#")]),s._v(" 创建视图")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("CREATE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("VIEW")]),s._v(" top_10_user_view "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("AS")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" id"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v(" username\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" id "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("<")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("10")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"删除视图"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#删除视图"}},[s._v("#")]),s._v(" 删除视图")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DROP")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("VIEW")]),s._v(" top_10_user_view"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"索引-index"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#索引-index"}},[s._v("#")]),s._v(" 索引（INDEX）")]),s._v(" "),t("blockquote",[t("p",[s._v("通过索引可以更加快速高效地查询数据。用户无法看到索引，它们只能被用来加速查询。")])]),s._v(" "),t("p",[s._v("更新一个包含索引的表需要比更新一个没有索引的表花费更多的时间，这是由于索引本身也需要更新。因此，理想的做法是仅仅在常常被搜索的列（以及表）上面创建索引。")]),s._v(" "),t("p",[s._v("唯一索引：唯一索引表明此索引的每一个索引值只对应唯一的数据记录。")]),s._v(" "),t("h4",{attrs:{id:"创建索引"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#创建索引"}},[s._v("#")]),s._v(" 创建索引")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("CREATE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INDEX")]),s._v(" idx_email\n "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ON")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("email"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"创建唯一索引"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#创建唯一索引"}},[s._v("#")]),s._v(" 创建唯一索引")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("CREATE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("UNIQUE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INDEX")]),s._v(" uniq_username\n "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ON")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("username"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"删除索引"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#删除索引"}},[s._v("#")]),s._v(" 删除索引")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ALTER")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DROP")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INDEX")]),s._v(" idx_email"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ALTER")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DROP")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INDEX")]),s._v(" uniq_username"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"添加主键"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#添加主键"}},[s._v("#")]),s._v(" 添加主键")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ALTER")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ADD")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("PRIMARY")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("KEY")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("id"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h4",{attrs:{id:"删除主键"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#删除主键"}},[s._v("#")]),s._v(" 删除主键")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ALTER")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("user")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DROP")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("PRIMARY")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("KEY")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"约束"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#约束"}},[s._v("#")]),s._v(" 约束")]),s._v(" "),t("blockquote",[t("p",[s._v("SQL 约束用于规定表中的数据规则。")])]),s._v(" "),t("ul",[t("li",[s._v("如果存在违反约束的数据行为，行为会被约束终止。")]),s._v(" "),t("li",[s._v("约束可以在创建表时规定（通过 CREATE TABLE 语句），或者在表创建之后规定（通过 ALTER TABLE 语句）。")]),s._v(" "),t("li",[s._v("约束类型\n"),t("ul",[t("li",[t("code",[s._v("NOT NULL")]),s._v(" - 指示某列不能存储 NULL 值。")]),s._v(" "),t("li",[t("code",[s._v("UNIQUE")]),s._v(" - 保证某列的每行必须有唯一的值。")]),s._v(" "),t("li",[t("code",[s._v("PRIMARY KEY")]),s._v(" - NOT NULL 和 UNIQUE 的结合。确保某列（或两个列多个列的结合）有唯一标识，有助于更容易更快速地找到表中的一个特定的记录。")]),s._v(" "),t("li",[t("code",[s._v("FOREIGN KEY")]),s._v(" - 保证一个表中的数据匹配另一个表中的值的参照完整性。")]),s._v(" "),t("li",[t("code",[s._v("CHECK")]),s._v(" - 保证列中的值符合指定的条件。")]),s._v(" "),t("li",[t("code",[s._v("DEFAULT")]),s._v(" - 规定没有给列赋值时的默认值。")])])])]),s._v(" "),t("p",[s._v("创建表时使用约束条件：")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("CREATE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" Users "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("\n Id "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INT")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("10")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("UNSIGNED")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("NOT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("AUTO_INCREMENT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COMMENT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'自增Id'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v("\n Username "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("VARCHAR")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("64")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("NOT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("UNIQUE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DEFAULT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'default'")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COMMENT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'用户名'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v("\n Password "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("VARCHAR")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("64")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("NOT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DEFAULT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'default'")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COMMENT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'密码'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v("\n Email "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("VARCHAR")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("64")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("NOT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DEFAULT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'default'")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COMMENT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'邮箱地址'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v("\n Enabled "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TINYINT")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("4")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DEFAULT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COMMENT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'是否有效'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),s._v("\n "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("PRIMARY")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("KEY")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("Id"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ENGINE")]),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("InnoDB")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("AUTO_INCREMENT")]),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("2")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("DEFAULT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("CHARSET")]),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v("utf8mb4 "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COMMENT")]),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'用户表'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h2",{attrs:{id:"参考资料"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#参考资料"}},[s._v("#")]),s._v(" 参考资料")]),s._v(" "),t("ul",[t("li",[t("a",{attrs:{href:"https://book.douban.com/subject/35167240/",target:"_blank",rel:"noopener noreferrer"}},[s._v("《SQL 必知必会》"),t("OutboundLink")],1)]),s._v(" "),t("li",[t("a",{attrs:{href:"https://draveness.me/mysql-transaction",target:"_blank",rel:"noopener noreferrer"}},[s._v("『浅入深出』MySQL 中事务的实现"),t("OutboundLink")],1)]),s._v(" "),t("li",[t("a",{attrs:{href:"https://www.cnblogs.com/CraryPrimitiveMan/p/4206942.html",target:"_blank",rel:"noopener noreferrer"}},[s._v("MySQL 的学习--触发器"),t("OutboundLink")],1)]),s._v(" "),t("li",[t("a",{attrs:{href:"https://zh.wikipedia.org/wiki/SQL",target:"_blank",rel:"noopener noreferrer"}},[s._v("维基百科词条 - SQL"),t("OutboundLink")],1)]),s._v(" "),t("li",[t("a",{attrs:{href:"https://www.sitesbay.com/sql/index",target:"_blank",rel:"noopener noreferrer"}},[s._v("https://www.sitesbay.com/sql/index"),t("OutboundLink")],1)]),s._v(" "),t("li",[t("a",{attrs:{href:"https://www.w3resource.com/sql/subqueries/understanding-sql-subqueries.php",target:"_blank",rel:"noopener noreferrer"}},[s._v("SQL Subqueries"),t("OutboundLink")],1)]),s._v(" "),t("li",[t("a",{attrs:{href:"https://stackoverflow.com/questions/6294778/mysql-quick-breakdown-of-the-types-of-joins",target:"_blank",rel:"noopener noreferrer"}},[s._v("Quick breakdown of the types of joins"),t("OutboundLink")],1)]),s._v(" "),t("li",[t("a",{attrs:{href:"https://www.w3resource.com/sql/sql-union.php",target:"_blank",rel:"noopener noreferrer"}},[s._v("SQL UNION"),t("OutboundLink")],1)]),s._v(" "),t("li",[t("a",{attrs:{href:"https://www.w3resource.com/sql/database-security/create-users.php",target:"_blank",rel:"noopener noreferrer"}},[s._v("SQL database security"),t("OutboundLink")],1)]),s._v(" "),t("li",[t("a",{attrs:{href:"https://www.cnblogs.com/chenpi/p/5136483.html",target:"_blank",rel:"noopener noreferrer"}},[s._v("Mysql 中的存储过程"),t("OutboundLink")],1)])])])}),[],!1,null,null,null);t.default=r.exports}}]); \ No newline at end of file diff --git a/assets/js/14.06d1916b.js b/assets/js/14.06d1916b.js new file mode 100644 index 00000000..864e7a1c --- /dev/null +++ b/assets/js/14.06d1916b.js @@ -0,0 +1 @@ +(window.webpackJsonp=window.webpackJsonp||[]).push([[14],{351:function(t,s,a){"use strict";a.r(s);var e=a(4),n=Object(e.a)({},(function(){var t=this,s=t._self._c;return s("ContentSlotsDistributor",{attrs:{"slot-key":t.$parent.slotKey}},[s("h1",{attrs:{id:"sql-语法高级特性"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#sql-语法高级特性"}},[t._v("#")]),t._v(" SQL 语法高级特性")]),t._v(" "),s("blockquote",[s("p",[t._v("本文针对关系型数据库的基本语法。限于篇幅，本文侧重说明用法，不会展开讲解特性、原理。")]),t._v(" "),s("p",[t._v("本文语法主要针对 Mysql，但大部分的语法对其他关系型数据库也适用。")])]),t._v(" "),s("p",[s("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/snap/20200115160512.png",alt:"img"}})]),t._v(" "),s("h2",{attrs:{id:"连接和组合"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#连接和组合"}},[t._v("#")]),t._v(" 连接和组合")]),t._v(" "),s("h3",{attrs:{id:"连接-join"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#连接-join"}},[t._v("#")]),t._v(" 连接（JOIN）")]),t._v(" "),s("blockquote",[s("p",[t._v("连接用于连接多个表，使用 "),s("code",[t._v("JOIN")]),t._v(" 关键字，并且条件语句使用 "),s("code",[t._v("ON")]),t._v(" 而不是 "),s("code",[t._v("WHERE")]),t._v("。")])]),t._v(" "),s("p",[t._v("如果一个 "),s("code",[t._v("JOIN")]),t._v(" 至少有一个公共字段并且它们之间存在关系，则该 "),s("code",[t._v("JOIN")]),t._v(" 可以在两个或多个表上工作。")]),t._v(" "),s("p",[s("code",[t._v("JOIN")]),t._v(" 保持基表（结构和数据）不变。"),s("strong",[t._v("连接可以替换子查询，并且比子查询的效率一般会更快")]),t._v("。")]),t._v(" "),s("p",[s("code",[t._v("JOIN")]),t._v(" 有两种连接类型：内连接和外连接。")]),t._v(" "),s("div",{attrs:{align:"center"}},[s("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/mysql/sql-join.png",alt:"sql-join"}})]),t._v(" "),s("h4",{attrs:{id:"内连接-inner-join"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#内连接-inner-join"}},[t._v("#")]),t._v(" 内连接（INNER JOIN）")]),t._v(" "),s("p",[t._v("内连接又称等值连接，"),s("strong",[t._v("使用 "),s("code",[t._v("INNER JOIN")]),t._v(" 关键字")]),t._v("。在没有条件语句的情况下"),s("strong",[t._v("返回笛卡尔积")]),t._v("。")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" vend_name"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" prod_name"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" prod_price\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" vendors "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INNER")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("JOIN")]),t._v(" products\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ON")]),t._v(" vendors"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("vend_id "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" products"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("vend_id"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h5",{attrs:{id:"自连接"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#自连接"}},[t._v("#")]),t._v(" 自连接（"),s("code",[t._v("=")]),t._v("）")]),t._v(" "),s("p",[t._v("自连接可以看成内连接的一种，只是"),s("strong",[t._v("连接的表是自身")]),t._v("而已。"),s("strong",[t._v("自然连接是把同名列通过 "),s("code",[t._v("=")]),t._v(" 连接起来")]),t._v("的，同名列可以有多个。")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" c1"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_id"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" c1"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_name"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" c1"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_contact\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" customers c1"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" customers c2\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" c1"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_name "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" c2"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_name\n"),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("AND")]),t._v(" c2"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_contact "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'Jim Jones'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h5",{attrs:{id:"自然连接-natural-join"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#自然连接-natural-join"}},[t._v("#")]),t._v(" 自然连接（NATURAL JOIN）")]),t._v(" "),s("p",[t._v("内连接提供连接的列，而自然连接"),s("strong",[t._v("自动连接所有同名列")]),t._v("。自然连接使用 "),s("code",[t._v("NATURAL JOIN")]),t._v(" 关键字。")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" Products\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("NATURAL")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("JOIN")]),t._v(" Customers"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h4",{attrs:{id:"外连接-outer-join"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#外连接-outer-join"}},[t._v("#")]),t._v(" 外连接（OUTER JOIN）")]),t._v(" "),s("p",[t._v("外连接返回一个表中的所有行，并且仅返回来自此表中满足连接条件的那些行，即两个表中的列是相等的。外连接分为左外连接、右外连接、全外连接（Mysql 不支持）。")]),t._v(" "),s("h5",{attrs:{id:"左连接-left-join"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#左连接-left-join"}},[t._v("#")]),t._v(" 左连接（LEFT JOIN）")]),t._v(" "),s("p",[t._v("左外连接就是保留左表没有关联的行。")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" customers"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_id"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" orders"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("order_num\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" customers "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("LEFT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("JOIN")]),t._v(" orders\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ON")]),t._v(" customers"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_id "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" orders"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_id"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h5",{attrs:{id:"右连接-right-join"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#右连接-right-join"}},[t._v("#")]),t._v(" 右连接（RIGHT JOIN）")]),t._v(" "),s("p",[t._v("右外连接就是保留右表没有关联的行。")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" customers"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_id"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" orders"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("order_num\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" customers "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("RIGHT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("JOIN")]),t._v(" orders\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ON")]),t._v(" customers"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_id "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" orders"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("cust_id"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"组合-union"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#组合-union"}},[t._v("#")]),t._v(" 组合（UNION）")]),t._v(" "),s("blockquote",[s("p",[s("code",[t._v("UNION")]),t._v(" 运算符"),s("strong",[t._v("将两个或更多查询的结果组合起来，并生成一个结果集")]),t._v("，其中包含来自 "),s("code",[t._v("UNION")]),t._v(" 中参与查询的提取行。")])]),t._v(" "),s("p",[s("code",[t._v("UNION")]),t._v(" 基本规则：")]),t._v(" "),s("ul",[s("li",[t._v("所有查询的列数和列顺序必须相同。")]),t._v(" "),s("li",[t._v("每个查询中涉及表的列的数据类型必须相同或兼容。")]),t._v(" "),s("li",[t._v("通常返回的列名取自第一个查询。")])]),t._v(" "),s("p",[t._v("默认会去除相同行，如果需要保留相同行，使用 "),s("code",[t._v("UNION ALL")]),t._v("。")]),t._v(" "),s("p",[t._v("只能包含一个 "),s("code",[t._v("ORDER BY")]),t._v(" 子句，并且必须位于语句的最后。")]),t._v(" "),s("p",[t._v("应用场景：")]),t._v(" "),s("ul",[s("li",[t._v("在一个查询中从不同的表返回结构数据。")]),t._v(" "),s("li",[t._v("对一个表执行多个查询，按一个查询返回数据。")])]),t._v(" "),s("p",[t._v("组合查询示例：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" cust_name"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" cust_contact"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" cust_email\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" customers\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" cust_state "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("IN")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'IL'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'IN'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'MI'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("UNION")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" cust_name"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" cust_contact"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" cust_email\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" customers\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" cust_name "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'Fun4All'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"join-vs-union"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#join-vs-union"}},[t._v("#")]),t._v(" JOIN vs UNION")]),t._v(" "),s("ul",[s("li",[s("code",[t._v("JOIN")]),t._v(" 中连接表的列可能不同，但在 "),s("code",[t._v("UNION")]),t._v(" 中，所有查询的列数和列顺序必须相同。")]),t._v(" "),s("li",[s("code",[t._v("UNION")]),t._v(" 将查询之后的行放在一起（垂直放置），但 "),s("code",[t._v("JOIN")]),t._v(" 将查询之后的列放在一起（水平放置），即它构成一个笛卡尔积。")])]),t._v(" "),s("h2",{attrs:{id:"函数"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#函数"}},[t._v("#")]),t._v(" 函数")]),t._v(" "),s("blockquote",[s("p",[t._v("🔔 注意：不同数据库的函数往往各不相同，因此不可移植。本节主要以 Mysql 的函数为例。")])]),t._v(" "),s("h3",{attrs:{id:"文本处理"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#文本处理"}},[t._v("#")]),t._v(" 文本处理")]),t._v(" "),s("table",[s("thead",[s("tr",[s("th",{staticStyle:{"text-align":"center"}},[t._v("函数")]),t._v(" "),s("th",{staticStyle:{"text-align":"center"}},[t._v("说明")])])]),t._v(" "),s("tbody",[s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("LEFT()")]),t._v("、"),s("code",[t._v("RIGHT()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("左边或者右边的字符")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("LOWER()")]),t._v("、"),s("code",[t._v("UPPER()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("转换为小写或者大写")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("LTRIM()")]),t._v("、"),s("code",[t._v("RTIM()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("去除左边或者右边的空格")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("LENGTH()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("长度")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("SOUNDEX()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("转换为语音值")])])])]),t._v(" "),s("p",[t._v("其中， "),s("strong",[t._v("SOUNDEX()")]),t._v(" 可以将一个字符串转换为描述其语音表示的字母数字模式。")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" mytable\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" SOUNDEX"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("col1"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" SOUNDEX"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'apple'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n")])])]),s("h3",{attrs:{id:"日期和时间处理"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#日期和时间处理"}},[t._v("#")]),t._v(" 日期和时间处理")]),t._v(" "),s("ul",[s("li",[t._v("日期格式："),s("code",[t._v("YYYY-MM-DD")])]),t._v(" "),s("li",[t._v("时间格式："),s("code",[t._v("HH:MM:SS")])])]),t._v(" "),s("table",[s("thead",[s("tr",[s("th",{staticStyle:{"text-align":"center"}},[t._v("函 数")]),t._v(" "),s("th",{staticStyle:{"text-align":"center"}},[t._v("说 明")])])]),t._v(" "),s("tbody",[s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("AddDate()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("增加一个日期（天、周等）")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("AddTime()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("增加一个时间（时、分等）")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("CurDate()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回当前日期")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("CurTime()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回当前时间")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("Date()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回日期时间的日期部分")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("DateDiff()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("计算两个日期之差")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("Date_Add()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("高度灵活的日期运算函数")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("Date_Format()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回一个格式化的日期或时间串")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("Day()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回一个日期的天数部分")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("DayOfWeek()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("对于一个日期，返回对应的星期几")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("Hour()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回一个时间的小时部分")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("Minute()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回一个时间的分钟部分")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("Month()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回一个日期的月份部分")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("Now()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回当前日期和时间")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("Second()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回一个时间的秒部分")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("Time()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回一个日期时间的时间部分")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("Year()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回一个日期的年份部分")])])])]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[t._v("mysql"),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v(">")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token function"}},[t._v("NOW")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("div",{staticClass:"language- extra-class"},[s("pre",{pre:!0,attrs:{class:"language-text"}},[s("code",[t._v("2018-4-14 20:25:11\n")])])]),s("h3",{attrs:{id:"数值处理"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#数值处理"}},[t._v("#")]),t._v(" 数值处理")]),t._v(" "),s("table",[s("thead",[s("tr",[s("th",{staticStyle:{"text-align":"center"}},[t._v("函数")]),t._v(" "),s("th",{staticStyle:{"text-align":"center"}},[t._v("说明")])])]),t._v(" "),s("tbody",[s("tr",[s("td",{staticStyle:{"text-align":"center"}},[t._v("SIN()")]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("正弦")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[t._v("COS()")]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("余弦")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[t._v("TAN()")]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("正切")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[t._v("ABS()")]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("绝对值")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[t._v("SQRT()")]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("平方根")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[t._v("MOD()")]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("余数")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[t._v("EXP()")]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("指数")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[t._v("PI()")]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("圆周率")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[t._v("RAND()")]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("随机数")])])])]),t._v(" "),s("h3",{attrs:{id:"汇总"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#汇总"}},[t._v("#")]),t._v(" 汇总")]),t._v(" "),s("table",[s("thead",[s("tr",[s("th",{staticStyle:{"text-align":"center"}},[t._v("函 数")]),t._v(" "),s("th",{staticStyle:{"text-align":"center"}},[t._v("说 明")])])]),t._v(" "),s("tbody",[s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("AVG()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回某列的平均值")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("COUNT()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回某列的行数")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("MAX()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回某列的最大值")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("MIN()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回某列的最小值")])]),t._v(" "),s("tr",[s("td",{staticStyle:{"text-align":"center"}},[s("code",[t._v("SUM()")])]),t._v(" "),s("td",{staticStyle:{"text-align":"center"}},[t._v("返回某列值之和")])])])]),t._v(" "),s("p",[s("code",[t._v("AVG()")]),t._v(" 会忽略 NULL 行。")]),t._v(" "),s("p",[t._v("使用 DISTINCT 可以让汇总函数值汇总不同的值。")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token function"}},[t._v("AVG")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DISTINCT")]),t._v(" col1"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("AS")]),t._v(" avg_col\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" mytable\n")])])]),s("h2",{attrs:{id:"分组"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#分组"}},[t._v("#")]),t._v(" 分组")]),t._v(" "),s("h3",{attrs:{id:"group-by"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#group-by"}},[t._v("#")]),t._v(" GROUP BY")]),t._v(" "),s("blockquote",[s("p",[s("code",[t._v("GROUP BY")]),t._v(" 子句将记录分组到汇总行中，"),s("code",[t._v("GROUP BY")]),t._v(" 为每个组返回一个记录。")])]),t._v(" "),s("p",[s("code",[t._v("GROUP BY")]),t._v(" 可以按一列或多列进行分组。")]),t._v(" "),s("p",[s("code",[t._v("GROUP BY")]),t._v(" 通常还涉及聚合函数：COUNT，MAX，SUM，AVG 等。")]),t._v(" "),s("p",[s("code",[t._v("GROUP BY")]),t._v(" 按分组字段进行排序后，"),s("code",[t._v("ORDER BY")]),t._v(" 可以以汇总字段来进行排序。")]),t._v(" "),s("p",[t._v("分组示例：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" cust_name"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token function"}},[t._v("COUNT")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("cust_address"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("AS")]),t._v(" addr_num\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" Customers "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("GROUP")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BY")]),t._v(" cust_name"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("p",[t._v("分组后排序示例：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" cust_name"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token function"}},[t._v("COUNT")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("cust_address"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("AS")]),t._v(" addr_num\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" Customers "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("GROUP")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BY")]),t._v(" cust_name\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ORDER")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BY")]),t._v(" cust_name "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DESC")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"having"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#having"}},[t._v("#")]),t._v(" HAVING")]),t._v(" "),s("blockquote",[s("p",[s("code",[t._v("HAVING")]),t._v(" 用于对汇总的 "),s("code",[t._v("GROUP BY")]),t._v(" 结果进行过滤。"),s("code",[t._v("HAVING")]),t._v(" 要求存在一个 "),s("code",[t._v("GROUP BY")]),t._v(" 子句。")])]),t._v(" "),s("p",[s("code",[t._v("WHERE")]),t._v(" 和 "),s("code",[t._v("HAVING")]),t._v(" 可以在相同的查询中。")]),t._v(" "),s("p",[s("code",[t._v("HAVING")]),t._v(" vs "),s("code",[t._v("WHERE")]),t._v("：")]),t._v(" "),s("ul",[s("li",[s("code",[t._v("WHERE")]),t._v(" 和 "),s("code",[t._v("HAVING")]),t._v(" 都是用于过滤。")]),t._v(" "),s("li",[s("code",[t._v("HAVING")]),t._v(" 适用于汇总的组记录；而 "),s("code",[t._v("WHERE")]),t._v(" 适用于单个记录。")])]),t._v(" "),s("p",[t._v("使用 "),s("code",[t._v("WHERE")]),t._v(" 和 "),s("code",[t._v("HAVING")]),t._v(" 过滤数据示例：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" cust_name"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token function"}},[t._v("COUNT")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("AS")]),t._v(" num\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" Customers\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" cust_email "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("IS")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("NOT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token boolean"}},[t._v("NULL")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("GROUP")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BY")]),t._v(" cust_name\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("HAVING")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token function"}},[t._v("COUNT")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v(">=")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token number"}},[t._v("1")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("hr"),t._v(" "),s("p",[s("strong",[t._v("（以下为 DDL 语句用法）")])]),t._v(" "),s("h2",{attrs:{id:"事务"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#事务"}},[t._v("#")]),t._v(" 事务")]),t._v(" "),s("p",[t._v("不能回退 "),s("code",[t._v("SELECT")]),t._v(" 语句，回退 "),s("code",[t._v("SELECT")]),t._v(" 语句也没意义；也不能回退 "),s("code",[t._v("CREATE")]),t._v(" 和 "),s("code",[t._v("DROP")]),t._v(" 语句。")]),t._v(" "),s("p",[s("strong",[t._v("MySQL 默认采用隐式提交策略（"),s("code",[t._v("autocommit")]),t._v("）")]),t._v("，每执行一条语句就把这条语句当成一个事务然后进行提交。当出现 "),s("code",[t._v("START TRANSACTION")]),t._v(" 语句时，会关闭隐式提交；当 "),s("code",[t._v("COMMIT")]),t._v(" 或 "),s("code",[t._v("ROLLBACK")]),t._v(" 语句执行后，事务会自动关闭，重新恢复隐式提交。")]),t._v(" "),s("p",[t._v("通过 "),s("code",[t._v("set autocommit=0")]),t._v(" 可以取消自动提交，直到 "),s("code",[t._v("set autocommit=1")]),t._v(" 才会提交；"),s("code",[t._v("autocommit")]),t._v(" 标记是针对每个连接而不是针对服务器的。")]),t._v(" "),s("p",[t._v("事务处理指令：")]),t._v(" "),s("ul",[s("li",[s("code",[t._v("START TRANSACTION")]),t._v(" - 指令用于标记事务的起始点。")]),t._v(" "),s("li",[s("code",[t._v("SAVEPOINT")]),t._v(" - 指令用于创建保留点。")]),t._v(" "),s("li",[s("code",[t._v("ROLLBACK TO")]),t._v(" - 指令用于回滚到指定的保留点；如果没有设置保留点，则回退到 "),s("code",[t._v("START TRANSACTION")]),t._v(" 语句处。")]),t._v(" "),s("li",[s("code",[t._v("COMMIT")]),t._v(" - 提交事务。")]),t._v(" "),s("li",[s("code",[t._v("RELEASE SAVEPOINT")]),t._v("：删除某个保存点。")]),t._v(" "),s("li",[s("code",[t._v("SET TRANSACTION")]),t._v("：设置事务的隔离级别。")])]),t._v(" "),s("p",[t._v("事务处理示例：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 开始事务")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("START")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("TRANSACTION")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n\n"),s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 插入操作 A")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INSERT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INTO")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token identifier"}},[s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")]),t._v("user"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")])]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("VALUES")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token number"}},[t._v("1")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'root1'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'root1'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'xxxx@163.com'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n\n"),s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 创建保留点 updateA")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SAVEPOINT")]),t._v(" updateA"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n\n"),s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 插入操作 B")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INSERT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INTO")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token identifier"}},[s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")]),t._v("user"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")])]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("VALUES")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token number"}},[t._v("2")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'root2'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'root2'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'xxxx@163.com'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n\n"),s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 回滚到保留点 updateA")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ROLLBACK")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("TO")]),t._v(" updateA"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n\n"),s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 提交事务，只有操作 A 生效")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("COMMIT")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"acid"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#acid"}},[t._v("#")]),t._v(" ACID")]),t._v(" "),s("h3",{attrs:{id:"事务隔离级别"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#事务隔离级别"}},[t._v("#")]),t._v(" 事务隔离级别")]),t._v(" "),s("hr"),t._v(" "),s("p",[s("strong",[t._v("（以下为 DCL 语句用法）")])]),t._v(" "),s("h2",{attrs:{id:"权限控制"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#权限控制"}},[t._v("#")]),t._v(" 权限控制")]),t._v(" "),s("p",[s("code",[t._v("GRANT")]),t._v(" 和 "),s("code",[t._v("REVOKE")]),t._v(" 可在几个层次上控制访问权限：")]),t._v(" "),s("ul",[s("li",[t._v("整个服务器，使用 "),s("code",[t._v("GRANT ALL")]),t._v(" 和 "),s("code",[t._v("REVOKE ALL")]),t._v("；")]),t._v(" "),s("li",[t._v("整个数据库，使用 ON database.*；")]),t._v(" "),s("li",[t._v("特定的表，使用 ON database.table；")]),t._v(" "),s("li",[t._v("特定的列；")]),t._v(" "),s("li",[t._v("特定的存储过程。")])]),t._v(" "),s("p",[t._v("新创建的账户没有任何权限。")]),t._v(" "),s("p",[t._v("账户用 "),s("code",[t._v("username@host")]),t._v(" 的形式定义，"),s("code",[t._v("username@%")]),t._v(" 使用的是默认主机名。")]),t._v(" "),s("p",[t._v("MySQL 的账户信息保存在 mysql 这个数据库中。")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("USE")]),t._v(" mysql"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("user")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("user")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"创建账户"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#创建账户"}},[t._v("#")]),t._v(" 创建账户")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("CREATE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("USER")]),t._v(" myuser IDENTIFIED "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BY")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'mypassword'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"修改账户名"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#修改账户名"}},[t._v("#")]),t._v(" 修改账户名")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("UPDATE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("user")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SET")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("user")]),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'newuser'")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHERE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("user")]),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'myuser'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\nFLUSH "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("PRIVILEGES")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"删除账户"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#删除账户"}},[t._v("#")]),t._v(" 删除账户")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DROP")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("USER")]),t._v(" myuser"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"查看权限"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#查看权限"}},[t._v("#")]),t._v(" 查看权限")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SHOW")]),t._v(" GRANTS "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FOR")]),t._v(" myuser"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"授予权限"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#授予权限"}},[t._v("#")]),t._v(" 授予权限")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("GRANT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INSERT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ON")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("TO")]),t._v(" myuser"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"删除权限"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#删除权限"}},[t._v("#")]),t._v(" 删除权限")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("REVOKE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INSERT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ON")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FROM")]),t._v(" myuser"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"更改密码"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#更改密码"}},[t._v("#")]),t._v(" 更改密码")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SET")]),t._v(" PASSWORD "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FOR")]),t._v(" myuser "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'mypass'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h2",{attrs:{id:"存储过程"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#存储过程"}},[t._v("#")]),t._v(" 存储过程")]),t._v(" "),s("p",[t._v("存储过程的英文是 Stored Procedure。它可以视为一组 SQL 语句的批处理。一旦存储过程被创建出来，使用它就像使用函数一样简单，我们直接通过调用存储过程名即可。")]),t._v(" "),s("p",[t._v("定义存储过程的语法格式：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("CREATE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("PROCEDURE")]),t._v(" 存储过程名称 "),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("[")]),t._v("参数列表"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("]")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BEGIN")]),t._v("\n 需要执行的语句\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("END")]),t._v("\n")])])]),s("p",[t._v("存储过程定义语句类型：")]),t._v(" "),s("ul",[s("li",[s("code",[t._v("CREATE PROCEDURE")]),t._v(" 用于创建存储过程")]),t._v(" "),s("li",[s("code",[t._v("DROP PROCEDURE")]),t._v(" 用于删除存储过程")]),t._v(" "),s("li",[s("code",[t._v("ALTER PROCEDURE")]),t._v(" 用于修改存储过程")])]),t._v(" "),s("h3",{attrs:{id:"使用存储过程"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#使用存储过程"}},[t._v("#")]),t._v(" 使用存储过程")]),t._v(" "),s("p",[t._v("创建存储过程的要点：")]),t._v(" "),s("ul",[s("li",[s("code",[t._v("DELIMITER")]),t._v(" 用于定义语句的结束符")]),t._v(" "),s("li",[t._v("存储过程的 3 种参数类型：\n"),s("ul",[s("li",[s("code",[t._v("IN")]),t._v("：存储过程的入参")]),t._v(" "),s("li",[s("code",[t._v("OUT")]),t._v("：存储过程的出参")]),t._v(" "),s("li",[s("code",[t._v("INPUT")]),t._v("：既是存储过程的入参，也是存储过程的出参")])])]),t._v(" "),s("li",[t._v("流控制语句：\n"),s("ul",[s("li",[s("code",[t._v("BEGIN…END")]),t._v("："),s("code",[t._v("BEGIN…END")]),t._v(" 中间包含了多个语句，每个语句都以（"),s("code",[t._v(";")]),t._v("）号为结束符。")]),t._v(" "),s("li",[s("code",[t._v("DECLARE")]),t._v("："),s("code",[t._v("DECLARE")]),t._v(" 用来声明变量，使用的位置在于 "),s("code",[t._v("BEGIN…END")]),t._v(" 语句中间，而且需要在其他语句使用之前进行变量的声明。")]),t._v(" "),s("li",[s("code",[t._v("SET")]),t._v("：赋值语句，用于对变量进行赋值。")]),t._v(" "),s("li",[s("code",[t._v("SELECT…INTO")]),t._v("：把从数据表中查询的结果存放到变量中，也就是为变量赋值。每次只能给一个变量赋值，不支持集合的操作。")]),t._v(" "),s("li",[s("code",[t._v("IF…THEN…ENDIF")]),t._v("：条件判断语句，可以在 "),s("code",[t._v("IF…THEN…ENDIF")]),t._v(" 中使用 "),s("code",[t._v("ELSE")]),t._v(" 和 "),s("code",[t._v("ELSEIF")]),t._v(" 来进行条件判断。")]),t._v(" "),s("li",[s("code",[t._v("CASE")]),t._v("："),s("code",[t._v("CASE")]),t._v(" 语句用于多条件的分支判断。")])])])]),t._v(" "),s("p",[t._v("创建存储过程示例：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DROP")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("PROCEDURE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("IF")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("EXISTS")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token identifier"}},[s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")]),t._v("proc_adder"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")])]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DELIMITER")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("CREATE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DEFINER")]),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),s("span",{pre:!0,attrs:{class:"token identifier"}},[s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")]),t._v("root"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")])]),s("span",{pre:!0,attrs:{class:"token variable"}},[t._v("@`localhost`")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("PROCEDURE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token identifier"}},[s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")]),t._v("proc_adder"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")])]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("IN")]),t._v(" a "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("int")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("IN")]),t._v(" b "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("int")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("OUT")]),t._v(" sum "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("int")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BEGIN")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DECLARE")]),t._v(" c "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("int")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("if")]),t._v(" a "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("is")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token boolean"}},[t._v("null")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("then")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("set")]),t._v(" a "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token number"}},[t._v("0")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("end")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("if")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("if")]),t._v(" b "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("is")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token boolean"}},[t._v("null")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("then")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("set")]),t._v(" b "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token number"}},[t._v("0")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("end")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("if")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("set")]),t._v(" sum "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" a "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),t._v(" b"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("END")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DELIMITER")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("p",[t._v("使用存储过程示例：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("set")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token variable"}},[t._v("@b")]),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),s("span",{pre:!0,attrs:{class:"token number"}},[t._v("5")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("call")]),t._v(" proc_adder"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token number"}},[t._v("2")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),s("span",{pre:!0,attrs:{class:"token variable"}},[t._v("@b")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),s("span",{pre:!0,attrs:{class:"token variable"}},[t._v("@s")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("select")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token variable"}},[t._v("@s")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("as")]),t._v(" sum"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h3",{attrs:{id:"存储过程的利弊"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#存储过程的利弊"}},[t._v("#")]),t._v(" 存储过程的利弊")]),t._v(" "),s("p",[t._v("存储过程的优点：")]),t._v(" "),s("ul",[s("li",[s("strong",[t._v("执行效率高")]),t._v("：一次编译多次使用。")]),t._v(" "),s("li",[s("strong",[t._v("安全性强")]),t._v("：在设定存储过程的时候可以设置对用户的使用权限，这样就和视图一样具有较强的安全性。")]),t._v(" "),s("li",[s("strong",[t._v("可复用")]),t._v("：将代码封装，可以提高代码复用。")]),t._v(" "),s("li",[s("strong",[t._v("性能好")]),t._v(" "),s("ul",[s("li",[t._v("由于是预先编译，因此具有很高的性能。")]),t._v(" "),s("li",[t._v("一个存储过程替代大量 T_SQL 语句 ，可以降低网络通信量，提高通信速率。")])])])]),t._v(" "),s("p",[t._v("存储过程的缺点：")]),t._v(" "),s("ul",[s("li",[s("strong",[t._v("可移植性差")]),t._v("：存储过程不能跨数据库移植。由于不同数据库的存储过程语法几乎都不一样，十分难以维护（不通用）。")]),t._v(" "),s("li",[s("strong",[t._v("调试困难")]),t._v("：只有少数 DBMS 支持存储过程的调试。对于复杂的存储过程来说，开发和维护都不容易。")]),t._v(" "),s("li",[s("strong",[t._v("版本管理困难")]),t._v("：比如数据表索引发生变化了，可能会导致存储过程失效。我们在开发软件的时候往往需要进行版本管理，但是存储过程本身没有版本控制，版本迭代更新的时候很麻烦。")]),t._v(" "),s("li",[s("strong",[t._v("不适合高并发的场景")]),t._v("：高并发的场景需要减少数据库的压力，有时数据库会采用分库分表的方式，而且对可扩展性要求很高，在这种情况下，存储过程会变得难以维护，增加数据库的压力，显然就不适用了。")])]),t._v(" "),s("blockquote",[s("p",[s("em",[t._v("综上，存储过程的优缺点都非常突出，是否使用一定要慎重，需要根据具体应用场景来权衡")]),t._v("。")])]),t._v(" "),s("h3",{attrs:{id:"触发器"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#触发器"}},[t._v("#")]),t._v(" 触发器")]),t._v(" "),s("blockquote",[s("p",[t._v("触发器可以视为一种特殊的存储过程。")]),t._v(" "),s("p",[t._v("触发器是一种与表操作有关的数据库对象，当触发器所在表上出现指定事件时，将调用该对象，即表的操作事件触发表上的触发器的执行。")])]),t._v(" "),s("h4",{attrs:{id:"触发器特性"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#触发器特性"}},[t._v("#")]),t._v(" 触发器特性")]),t._v(" "),s("p",[t._v("可以使用触发器来进行审计跟踪，把修改记录到另外一张表中。")]),t._v(" "),s("p",[t._v("MySQL 不允许在触发器中使用 "),s("code",[t._v("CALL")]),t._v(" 语句 ，也就是不能调用存储过程。")]),t._v(" "),s("p",[s("strong",[s("code",[t._v("BEGIN")]),t._v(" 和 "),s("code",[t._v("END")])])]),t._v(" "),s("p",[t._v("当触发器的触发条件满足时，将会执行 "),s("code",[t._v("BEGIN")]),t._v(" 和 "),s("code",[t._v("END")]),t._v(" 之间的触发器执行动作。")]),t._v(" "),s("blockquote",[s("p",[t._v("🔔 注意：在 MySQL 中，分号 "),s("code",[t._v(";")]),t._v(" 是语句结束的标识符，遇到分号表示该段语句已经结束，MySQL 可以开始执行了。因此，解释器遇到触发器执行动作中的分号后就开始执行，然后会报错，因为没有找到和 BEGIN 匹配的 END。")]),t._v(" "),s("p",[t._v("这时就会用到 "),s("code",[t._v("DELIMITER")]),t._v(" 命令（"),s("code",[t._v("DELIMITER")]),t._v(" 是定界符，分隔符的意思）。它是一条命令，不需要语句结束标识，语法为："),s("code",[t._v("DELIMITER new_delemiter")]),t._v("。"),s("code",[t._v("new_delemiter")]),t._v(" 可以设为 1 个或多个长度的符号，默认的是分号 "),s("code",[t._v(";")]),t._v("，我们可以把它修改为其他符号，如 "),s("code",[t._v("$")]),t._v(" - "),s("code",[t._v("DELIMITER $")]),t._v(" 。在这之后的语句，以分号结束，解释器不会有什么反应，只有遇到了 "),s("code",[t._v("$")]),t._v("，才认为是语句结束。注意，使用完之后，我们还应该记得把它给修改回来。")])]),t._v(" "),s("p",[s("strong",[s("code",[t._v("NEW")]),t._v(" 和 "),s("code",[t._v("OLD")])])]),t._v(" "),s("ul",[s("li",[t._v("MySQL 中定义了 "),s("code",[t._v("NEW")]),t._v(" 和 "),s("code",[t._v("OLD")]),t._v(" 关键字，用来表示触发器的所在表中，触发了触发器的那一行数据。")]),t._v(" "),s("li",[t._v("在 "),s("code",[t._v("INSERT")]),t._v(" 型触发器中，"),s("code",[t._v("NEW")]),t._v(" 用来表示将要（"),s("code",[t._v("BEFORE")]),t._v("）或已经（"),s("code",[t._v("AFTER")]),t._v("）插入的新数据；")]),t._v(" "),s("li",[t._v("在 "),s("code",[t._v("UPDATE")]),t._v(" 型触发器中，"),s("code",[t._v("OLD")]),t._v(" 用来表示将要或已经被修改的原数据，"),s("code",[t._v("NEW")]),t._v(" 用来表示将要或已经修改为的新数据；")]),t._v(" "),s("li",[t._v("在 "),s("code",[t._v("DELETE")]),t._v(" 型触发器中，"),s("code",[t._v("OLD")]),t._v(" 用来表示将要或已经被删除的原数据；")]),t._v(" "),s("li",[t._v("使用方法： "),s("code",[t._v("NEW.columnName")]),t._v(" （columnName 为相应数据表某一列名）")])]),t._v(" "),s("h4",{attrs:{id:"触发器指令"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#触发器指令"}},[t._v("#")]),t._v(" 触发器指令")]),t._v(" "),s("blockquote",[s("p",[t._v("提示：为了理解触发器的要点，有必要先了解一下创建触发器的指令。")])]),t._v(" "),s("p",[s("code",[t._v("CREATE TRIGGER")]),t._v(" 指令用于创建触发器。")]),t._v(" "),s("p",[t._v("语法：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("CREATE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("TRIGGER")]),t._v(" trigger_name\ntrigger_time\ntrigger_event\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ON")]),t._v(" table_name\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FOR EACH ROW")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BEGIN")]),t._v("\n trigger_statements\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("END")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("p",[t._v("说明：")]),t._v(" "),s("ul",[s("li",[t._v("trigger_name：触发器名")]),t._v(" "),s("li",[t._v("trigger_time: 触发器的触发时机。取值为 "),s("code",[t._v("BEFORE")]),t._v(" 或 "),s("code",[t._v("AFTER")]),t._v("。")]),t._v(" "),s("li",[t._v("trigger_event: 触发器的监听事件。取值为 "),s("code",[t._v("INSERT")]),t._v("、"),s("code",[t._v("UPDATE")]),t._v(" 或 "),s("code",[t._v("DELETE")]),t._v("。")]),t._v(" "),s("li",[t._v("table_name: 触发器的监听目标。指定在哪张表上建立触发器。")]),t._v(" "),s("li",[t._v("FOR EACH ROW: 行级监视，Mysql 固定写法，其他 DBMS 不同。")]),t._v(" "),s("li",[t._v("trigger_statements: 触发器执行动作。是一条或多条 SQL 语句的列表，列表内的每条语句都必须用分号 "),s("code",[t._v(";")]),t._v(" 来结尾。")])]),t._v(" "),s("p",[t._v("创建触发器示例：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DELIMITER")]),t._v(" $\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("CREATE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("TRIGGER")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token identifier"}},[s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")]),t._v("trigger_insert_user"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")])]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("AFTER")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INSERT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ON")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token identifier"}},[s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")]),t._v("user"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")])]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FOR EACH ROW")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BEGIN")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INSERT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INTO")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token identifier"}},[s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")]),t._v("user_history"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("`")])]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("user_id"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" operate_type"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" operate_time"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("VALUES")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("NEW"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(".")]),t._v("id"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token string"}},[t._v("'add a user'")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token function"}},[t._v("now")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("END")]),t._v(" $\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DELIMITER")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("p",[t._v("查看触发器示例：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SHOW")]),t._v(" TRIGGERS"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("p",[t._v("删除触发器示例：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DROP")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("TRIGGER")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("IF")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("EXISTS")]),t._v(" trigger_insert_user"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h2",{attrs:{id:"游标"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#游标"}},[t._v("#")]),t._v(" 游标")]),t._v(" "),s("blockquote",[s("p",[t._v("游标（CURSOR）是一个存储在 DBMS 服务器上的数据库查询，它不是一条 "),s("code",[t._v("SELECT")]),t._v(" 语句，而是被该语句检索出来的结果集。在存储过程中使用游标可以对一个结果集进行移动遍历。")])]),t._v(" "),s("p",[t._v("游标主要用于交互式应用，其中用户需要对数据集中的任意行进行浏览和修改。")]),t._v(" "),s("p",[t._v("使用游标的步骤：")]),t._v(" "),s("ol",[s("li",[s("strong",[t._v("定义游标")]),t._v("：通过 "),s("code",[t._v("DECLARE cursor_name CURSOR FOR <语句>")]),t._v(" 定义游标。这个过程没有实际检索出数据。")]),t._v(" "),s("li",[s("strong",[t._v("打开游标")]),t._v("：通过 "),s("code",[t._v("OPEN cursor_name")]),t._v(" 打开游标。")]),t._v(" "),s("li",[s("strong",[t._v("取出数据")]),t._v("：通过 "),s("code",[t._v("FETCH cursor_name INTO var_name ...")]),t._v(" 获取数据。")]),t._v(" "),s("li",[s("strong",[t._v("关闭游标")]),t._v("：通过 "),s("code",[t._v("CLOSE cursor_name")]),t._v(" 关闭游标。")]),t._v(" "),s("li",[s("strong",[t._v("释放游标")]),t._v("：通过 "),s("code",[t._v("DEALLOCATE PREPARE")]),t._v(" 释放游标。")])]),t._v(" "),s("p",[t._v("游标使用示例：")]),t._v(" "),s("div",{staticClass:"language-sql extra-class"},[s("pre",{pre:!0,attrs:{class:"language-sql"}},[s("code",[s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DELIMITER")]),t._v(" $\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("CREATE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("PROCEDURE")]),t._v(" getTotal"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("BEGIN")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DECLARE")]),t._v(" total "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INT")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 创建接收游标数据的变量")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DECLARE")]),t._v(" sid "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INT")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DECLARE")]),t._v(" sname "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("VARCHAR")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token number"}},[t._v("10")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 创建总数变量")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DECLARE")]),t._v(" sage "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INT")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 创建结束标志变量")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DECLARE")]),t._v(" done "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DEFAULT")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token boolean"}},[t._v("false")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 创建游标")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DECLARE")]),t._v(" cur "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("CURSOR")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FOR")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" id"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("name"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v("age "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("from")]),t._v(" cursor_table "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("where")]),t._v(" age"),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v(">")]),s("span",{pre:!0,attrs:{class:"token number"}},[t._v("30")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 指定游标循环结束时的返回值")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DECLARE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("CONTINUE")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("HANDLER")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FOR")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("NOT")]),t._v(" FOUND "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SET")]),t._v(" done "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token boolean"}},[t._v("true")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SET")]),t._v(" total "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token number"}},[t._v("0")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("OPEN")]),t._v(" cur"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FETCH")]),t._v(" cur "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INTO")]),t._v(" sid"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" sname"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" sage"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHILE")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("NOT")]),t._v(" done"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DO")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SET")]),t._v(" total "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" total "),s("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token number"}},[t._v("1")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("FETCH")]),t._v(" cur "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("INTO")]),t._v(" sid"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" sname"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(",")]),t._v(" sage"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("END")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("WHILE")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("CLOSE")]),t._v(" cur"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n "),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("SELECT")]),t._v(" total"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("END")]),t._v(" $\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("DELIMITER")]),t._v(" "),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n\n"),s("span",{pre:!0,attrs:{class:"token comment"}},[t._v("-- 调用存储过程")]),t._v("\n"),s("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("call")]),t._v(" getTotal"),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),s("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),s("h2",{attrs:{id:"参考资料"}},[s("a",{staticClass:"header-anchor",attrs:{href:"#参考资料"}},[t._v("#")]),t._v(" 参考资料")]),t._v(" "),s("ul",[s("li",[s("a",{attrs:{href:"https://book.douban.com/subject/35167240/",target:"_blank",rel:"noopener noreferrer"}},[t._v("《SQL 必知必会》"),s("OutboundLink")],1)]),t._v(" "),s("li",[s("a",{attrs:{href:"https://draveness.me/mysql-transaction",target:"_blank",rel:"noopener noreferrer"}},[t._v("『浅入深出』MySQL 中事务的实现"),s("OutboundLink")],1)]),t._v(" "),s("li",[s("a",{attrs:{href:"https://www.cnblogs.com/CraryPrimitiveMan/p/4206942.html",target:"_blank",rel:"noopener noreferrer"}},[t._v("MySQL 的学习--触发器"),s("OutboundLink")],1)]),t._v(" "),s("li",[s("a",{attrs:{href:"https://zh.wikipedia.org/wiki/SQL",target:"_blank",rel:"noopener noreferrer"}},[t._v("维基百科词条 - SQL"),s("OutboundLink")],1)]),t._v(" "),s("li",[s("a",{attrs:{href:"https://www.sitesbay.com/sql/index",target:"_blank",rel:"noopener noreferrer"}},[t._v("https://www.sitesbay.com/sql/index"),s("OutboundLink")],1)]),t._v(" "),s("li",[s("a",{attrs:{href:"https://www.w3resource.com/sql/subqueries/understanding-sql-subqueries.php",target:"_blank",rel:"noopener noreferrer"}},[t._v("SQL Subqueries"),s("OutboundLink")],1)]),t._v(" "),s("li",[s("a",{attrs:{href:"https://stackoverflow.com/questions/6294778/mysql-quick-breakdown-of-the-types-of-joins",target:"_blank",rel:"noopener noreferrer"}},[t._v("Quick breakdown of the types of joins"),s("OutboundLink")],1)]),t._v(" "),s("li",[s("a",{attrs:{href:"https://www.w3resource.com/sql/sql-union.php",target:"_blank",rel:"noopener noreferrer"}},[t._v("SQL UNION"),s("OutboundLink")],1)]),t._v(" "),s("li",[s("a",{attrs:{href:"https://www.w3resource.com/sql/database-security/create-users.php",target:"_blank",rel:"noopener noreferrer"}},[t._v("SQL database security"),s("OutboundLink")],1)]),t._v(" "),s("li",[s("a",{attrs:{href:"https://www.cnblogs.com/chenpi/p/5136483.html",target:"_blank",rel:"noopener noreferrer"}},[t._v("Mysql 中的存储过程"),s("OutboundLink")],1)])])])}),[],!1,null,null,null);s.default=n.exports}}]); \ No newline at end of file diff --git a/assets/js/15.c2e48c7a.js b/assets/js/15.c2e48c7a.js new file mode 100644 index 00000000..2a4744ff --- /dev/null +++ b/assets/js/15.c2e48c7a.js @@ -0,0 +1 @@ +(window.webpackJsonp=window.webpackJsonp||[]).push([[15],{352:function(s,t,a){"use strict";a.r(t);var r=a(4),e=Object(r.a)({},(function(){var s=this,t=s._self._c;return t("ContentSlotsDistributor",{attrs:{"slot-key":s.$parent.slotKey}},[t("h1",{attrs:{id:"扩展-sql"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#扩展-sql"}},[s._v("#")]),s._v(" 扩展 SQL")]),s._v(" "),t("h2",{attrs:{id:"数据库"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#数据库"}},[s._v("#")]),s._v(" 数据库")]),s._v(" "),t("h2",{attrs:{id:"表"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#表"}},[s._v("#")]),s._v(" 表")]),s._v(" "),t("h3",{attrs:{id:"查看表的基本信息"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#查看表的基本信息"}},[s._v("#")]),s._v(" 查看表的基本信息")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" information_schema"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(".")]),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("tables")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" table_schema "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'test'")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("AND")]),s._v(" table_name "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'user'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"查看表的列信息"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#查看表的列信息"}},[s._v("#")]),s._v(" 查看表的列信息")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SELECT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("*")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("FROM")]),s._v(" information_schema"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(".")]),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("columns")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("WHERE")]),s._v(" table_schema "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'test'")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("AND")]),s._v(" table_name "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("=")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token string"}},[s._v("'user'")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"如何批量删除大量数据"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#如何批量删除大量数据"}},[s._v("#")]),s._v(" 如何批量删除大量数据")]),s._v(" "),t("p",[s._v("如果要根据时间范围批量删除大量数据，最简单的语句如下：")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("delete")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("from")]),s._v(" orders\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("where")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("timestamp")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("<")]),s._v(" SUBDATE"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("CURDATE"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INTERVAL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("3")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("month")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("p",[s._v("上面的语句，大概率执行会报错，提示删除失败，因为需要删除的数据量太大了，所以需要分批删除。")]),s._v(" "),t("p",[s._v("可以先通过一次查询，找到符合条件的历史订单中最大的那个订单 ID，然后在删除语句中把删除的条件转换成按主键删除。")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("select")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token function"}},[s._v("max")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("id"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("from")]),s._v(" orders\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("where")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("timestamp")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("<")]),s._v(" SUBDATE"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),s._v("CURDATE"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(",")]),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("INTERVAL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("3")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("month")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n\n"),t("span",{pre:!0,attrs:{class:"token comment"}},[s._v("-- 分批删除，? 填上一条语句查到的最大 ID")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("delete")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("from")]),s._v(" orders\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("where")]),s._v(" id "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("<=")]),s._v(" ?\n"),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("order")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("by")]),s._v(" id "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("limit")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("1000")]),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h3",{attrs:{id:"修改表的编码格式"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#修改表的编码格式"}},[s._v("#")]),s._v(" 修改表的编码格式")]),s._v(" "),t("p",[s._v("utf8mb4 编码是 utf8 编码的超集，兼容 utf8，并且能存储 4 字节的表情字符。如果表的编码指定为 utf8，在保存 emoji 字段时会报错。")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("ALTER")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TABLE")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("<")]),s._v("tableName"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v(">")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("CONVERT")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("TO")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("CHARACTER")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("SET")]),s._v(" utf8mb4 "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("COLLATE")]),s._v(" utf8mb4_general_ci"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n")])])]),t("h2",{attrs:{id:"其他"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#其他"}},[s._v("#")]),s._v(" 其他")]),s._v(" "),t("h3",{attrs:{id:"显示哪些线程正在运行"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#显示哪些线程正在运行"}},[s._v("#")]),s._v(" 显示哪些线程正在运行")]),s._v(" "),t("div",{staticClass:"language-sql extra-class"},[t("pre",{pre:!0,attrs:{class:"language-sql"}},[t("code",[s._v("mysql"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v(">")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("show")]),s._v(" processlist"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(";")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("+")]),t("span",{pre:!0,attrs:{class:"token comment"}},[s._v("----+-----------------+-----------------+------+---------+-------+------------------------+------------------+")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" Id "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("User")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" Host "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" db "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" Command "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("Time")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" State "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" Info "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("+")]),t("span",{pre:!0,attrs:{class:"token comment"}},[s._v("----+-----------------+-----------------+------+---------+-------+------------------------+------------------+")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("5")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" event_scheduler "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" localhost "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" Daemon "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("40230")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" Waiting "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("on")]),s._v(" empty queue "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("10")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" root "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" localhost:"),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("10120")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token boolean"}},[s._v("NULL")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" Query "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("0")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" init "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("show")]),s._v(" processlist "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("|")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("+")]),t("span",{pre:!0,attrs:{class:"token comment"}},[s._v("----+-----------------+-----------------+------+---------+-------+------------------------+------------------+")]),s._v("\n"),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("2")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("rows")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token operator"}},[s._v("in")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token keyword"}},[s._v("set")]),s._v(" "),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v("(")]),t("span",{pre:!0,attrs:{class:"token number"}},[s._v("0.00")]),s._v(" sec"),t("span",{pre:!0,attrs:{class:"token punctuation"}},[s._v(")")]),s._v("\n")])])]),t("p",[s._v("Mysql 连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 "),t("code",[s._v("show processlist")]),s._v(" 命令中看到它。其中的 Command 列显示为“Sleep”的这一行，就表示现在系统里面有一个空闲连接。客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。")]),s._v(" "),t("h2",{attrs:{id:"参考资料"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#参考资料"}},[s._v("#")]),s._v(" 参考资料")]),s._v(" "),t("ul",[t("li",[t("a",{attrs:{href:"https://book.douban.com/subject/35167240/",target:"_blank",rel:"noopener noreferrer"}},[s._v("《SQL 必知必会》"),t("OutboundLink")],1)])])])}),[],!1,null,null,null);t.default=e.exports}}]); \ No newline at end of file diff --git a/assets/js/16.b3f19b44.js b/assets/js/16.b3f19b44.js new file mode 100644 index 00000000..daa205c7 --- /dev/null +++ b/assets/js/16.b3f19b44.js @@ -0,0 +1 @@ +(window.webpackJsonp=window.webpackJsonp||[]).push([[16],{353:function(_,v,e){"use strict";e.r(v);var a=e(4),o=Object(a.a)({},(function(){var _=this,v=_._self._c;return v("ContentSlotsDistributor",{attrs:{"slot-key":_.$parent.slotKey}},[v("h1",{attrs:{id:"sql-cheat-sheet"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#sql-cheat-sheet"}},[_._v("#")]),_._v(" SQL Cheat Sheet")]),_._v(" "),v("h2",{attrs:{id:"查找数据的查询"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#查找数据的查询"}},[_._v("#")]),_._v(" 查找数据的查询")]),_._v(" "),v("h3",{attrs:{id:"select-用于从数据库中选择数据"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#select-用于从数据库中选择数据"}},[_._v("#")]),_._v(" "),v("strong",[_._v("SELECT")]),_._v(": 用于从数据库中选择数据")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name;")])]),_._v(" "),v("h3",{attrs:{id:"distinct-用于过滤掉重复的值并返回指定列的行"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#distinct-用于过滤掉重复的值并返回指定列的行"}},[_._v("#")]),_._v(" "),v("strong",[_._v("DISTINCT")]),_._v(": 用于过滤掉重复的值并返回指定列的行")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT DISTINCT")]),_._v(" column_name;")])]),_._v(" "),v("h3",{attrs:{id:"where-用于过滤记录-行"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#where-用于过滤记录-行"}},[_._v("#")]),_._v(" "),v("strong",[_._v("WHERE")]),_._v(": 用于过滤记录/行")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" column1, column2 "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition;")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition1 "),v("code",[_._v("AND")]),_._v(" condition2;")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition1 "),v("code",[_._v("OR")]),_._v(" condition2;")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE NOT")]),_._v(" condition;")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition1 "),v("code",[_._v("AND")]),_._v(" (condition2 "),v("code",[_._v("OR")]),_._v(" condition3);")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE EXISTS")]),_._v(" ("),v("code",[_._v("SELECT")]),_._v(" column_name "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition);")])]),_._v(" "),v("h3",{attrs:{id:"order-by-用于结果集的排序-升序-asc-或者降序-desc"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#order-by-用于结果集的排序-升序-asc-或者降序-desc"}},[_._v("#")]),_._v(" "),v("strong",[_._v("ORDER BY")]),_._v(": 用于结果集的排序，升序（ASC）或者降序（DESC）")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("ORDER BY")]),_._v(" column;")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("ORDER BY")]),_._v(" column "),v("code",[_._v("DESC")]),_._v(";")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("ORDER BY")]),_._v(" column1 "),v("code",[_._v("ASC")]),_._v(", column2 "),v("code",[_._v("DESC")]),_._v(";")])]),_._v(" "),v("h3",{attrs:{id:"select-top-用于指定从表顶部返回的记录数"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#select-top-用于指定从表顶部返回的记录数"}},[_._v("#")]),_._v(" "),v("strong",[_._v("SELECT TOP")]),_._v(": 用于指定从表顶部返回的记录数")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT TOP")]),_._v(" number columns_names "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition;")]),_._v(" "),v("li",[v("code",[_._v("SELECT TOP")]),_._v(" percent columns_names "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition;")]),_._v(" "),v("li",[_._v("并非所有数据库系统都支持"),v("code",[_._v("SELECT TOP")]),_._v("。 MySQL 中是"),v("code",[_._v("LIMIT")]),_._v("子句")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" column_names "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("LIMIT")]),_._v(" offset, count;")])]),_._v(" "),v("h3",{attrs:{id:"like-用于搜索列中的特定模式-where-子句中使用的运算符"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#like-用于搜索列中的特定模式-where-子句中使用的运算符"}},[_._v("#")]),_._v(" "),v("strong",[_._v("LIKE")]),_._v(": 用于搜索列中的特定模式，WHERE 子句中使用的运算符")]),_._v(" "),v("ul",[v("li",[_._v("% (percent sign) 是一个表示零个，一个或多个字符的通配符")]),_._v(" "),v("li",[_._v("_ (underscore) 是一个表示单个字符通配符")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" column_names "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" column_name "),v("code",[_._v("LIKE")]),_._v(" pattern;")]),_._v(" "),v("li",[v("code",[_._v("LIKE")]),_._v(" ‘a%’ （查找任何以“a”开头的值）")]),_._v(" "),v("li",[v("code",[_._v("LIKE")]),_._v(" ‘%a’ （查找任何以“a”结尾的值）")]),_._v(" "),v("li",[v("code",[_._v("LIKE")]),_._v(" ‘%or%’ （查找任何包含“or”的值）")]),_._v(" "),v("li",[v("code",[_._v("LIKE")]),_._v(" ‘_r%’ （查找任何第二位是“r”的值）")]),_._v(" "),v("li",[v("code",[_._v("LIKE")]),_._v(" ‘a*%*%’ （查找任何以“a”开头且长度至少为 3 的值）")]),_._v(" "),v("li",[v("code",[_._v("LIKE")]),_._v(" ‘[a-c]%’（查找任何以“a”或“b”或“c”开头的值）")])]),_._v(" "),v("h3",{attrs:{id:"in-用于在-where-子句中指定多个值的运算符"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#in-用于在-where-子句中指定多个值的运算符"}},[_._v("#")]),_._v(" "),v("strong",[_._v("IN")]),_._v(": 用于在 WHERE 子句中指定多个值的运算符")]),_._v(" "),v("ul",[v("li",[_._v("本质上，IN 运算符是多个 OR 条件的简写")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" column_names "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" column_name "),v("code",[_._v("IN")]),_._v(" (value1, value2, …);")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" column_names "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" column_name "),v("code",[_._v("IN")]),_._v(" ("),v("code",[_._v("SELECT STATEMENT")]),_._v(");")])]),_._v(" "),v("h3",{attrs:{id:"between-用于过滤给定范围的值的运算符"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#between-用于过滤给定范围的值的运算符"}},[_._v("#")]),_._v(" "),v("strong",[_._v("BETWEEN")]),_._v(": 用于过滤给定范围的值的运算符")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" column_names "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" column_name "),v("code",[_._v("BETWEEN")]),_._v(" value1 "),v("code",[_._v("AND")]),_._v(" value2;")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" Products "),v("code",[_._v("WHERE")]),_._v(" (column_name "),v("code",[_._v("BETWEEN")]),_._v(" value1 "),v("code",[_._v("AND")]),_._v(" value2) "),v("code",[_._v("AND NOT")]),_._v(" column_name2 "),v("code",[_._v("IN")]),_._v(" (value3, value4);")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" Products "),v("code",[_._v("WHERE")]),_._v(" column_name "),v("code",[_._v("BETWEEN")]),_._v(" #01/07/1999# AND #03/12/1999#;")])]),_._v(" "),v("h3",{attrs:{id:"null-代表一个字段没有值"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#null-代表一个字段没有值"}},[_._v("#")]),_._v(" "),v("strong",[_._v("NULL")]),_._v(": 代表一个字段没有值")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" column_name "),v("code",[_._v("IS NULL")]),_._v(";")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" column_name "),v("code",[_._v("IS NOT NULL")]),_._v(";")])]),_._v(" "),v("h3",{attrs:{id:"as-用于给表或者列分配别名"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#as-用于给表或者列分配别名"}},[_._v("#")]),_._v(" "),v("strong",[_._v("AS")]),_._v(": 用于给表或者列分配别名")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" column_name "),v("code",[_._v("AS")]),_._v(" alias_name "),v("code",[_._v("FROM")]),_._v(" table_name;")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" column_name "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("AS")]),_._v(" alias_name;")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" column_name "),v("code",[_._v("AS")]),_._v(" alias_name1, column_name2 "),v("code",[_._v("AS")]),_._v(" alias_name2;")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" column_name1, column_name2 + ‘, ‘ + column_name3 "),v("code",[_._v("AS")]),_._v(" alias_name;")])]),_._v(" "),v("h3",{attrs:{id:"union-用于组合两个或者多个-select-语句的结果集的运算符"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#union-用于组合两个或者多个-select-语句的结果集的运算符"}},[_._v("#")]),_._v(" "),v("strong",[_._v("UNION")]),_._v(": 用于组合两个或者多个 SELECT 语句的结果集的运算符")]),_._v(" "),v("ul",[v("li",[_._v("每个 SELECT 语句必须拥有相同的列数")]),_._v(" "),v("li",[_._v("列必须拥有相似的数据类型")]),_._v(" "),v("li",[_._v("每个 SELECT 语句中的列也必须具有相同的顺序")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" columns_names "),v("code",[_._v("FROM")]),_._v(" table1 "),v("code",[_._v("UNION SELECT")]),_._v(" column_name "),v("code",[_._v("FROM")]),_._v(" table2;")]),_._v(" "),v("li",[v("code",[_._v("UNION")]),_._v(" 仅允许选择不同的值, "),v("code",[_._v("UNION ALL")]),_._v(" 允许重复")])]),_._v(" "),v("h3",{attrs:{id:"any-all-用于检查-where-或-having-子句中使用的子查询条件的运算符"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#any-all-用于检查-where-或-having-子句中使用的子查询条件的运算符"}},[_._v("#")]),_._v(" "),v("strong",[_._v("ANY|ALL")]),_._v(": 用于检查 WHERE 或 HAVING 子句中使用的子查询条件的运算符")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("ANY")]),_._v(" 如果任何子查询值满足条件，则返回 true。")]),_._v(" "),v("li",[v("code",[_._v("ALL")]),_._v(" 如果所有子查询值都满足条件，则返回 true。")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" columns_names "),v("code",[_._v("FROM")]),_._v(" table1 "),v("code",[_._v("WHERE")]),_._v(" column_name operator ("),v("code",[_._v("ANY")]),_._v("|"),v("code",[_._v("ALL")]),_._v(") ("),v("code",[_._v("SELECT")]),_._v(" column_name "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition);")])]),_._v(" "),v("h3",{attrs:{id:"group-by-通常与聚合函数-count-max-min-sum-avg-一起使用-用于将结果集分组为一列或多列"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#group-by-通常与聚合函数-count-max-min-sum-avg-一起使用-用于将结果集分组为一列或多列"}},[_._v("#")]),_._v(" "),v("strong",[_._v("GROUP BY")]),_._v(": 通常与聚合函数（COUNT，MAX，MIN，SUM，AVG）一起使用，用于将结果集分组为一列或多列")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" column_name1, COUNT(column_name2) "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition "),v("code",[_._v("GROUP BY")]),_._v(" column_name1 "),v("code",[_._v("ORDER BY")]),_._v(" COUNT(column_name2) DESC;")])]),_._v(" "),v("h3",{attrs:{id:"having-having-子句指定-select-语句应仅返回聚合值满足指定条件的行。它被添加到-sql-语言中-因为-where-关键字不能与聚合函数一起使用。"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#having-having-子句指定-select-语句应仅返回聚合值满足指定条件的行。它被添加到-sql-语言中-因为-where-关键字不能与聚合函数一起使用。"}},[_._v("#")]),_._v(" "),v("strong",[_._v("HAVING")]),_._v(": HAVING 子句指定 SELECT 语句应仅返回聚合值满足指定条件的行。它被添加到 SQL 语言中，因为 WHERE 关键字不能与聚合函数一起使用。")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" "),v("code",[_._v("COUNT")]),_._v("(column_name1), column_name2 "),v("code",[_._v("FROM")]),_._v(" table "),v("code",[_._v("GROUP BY")]),_._v(" column_name2 "),v("code",[_._v("HAVING")]),_._v(" "),v("code",[_._v("COUNT(")]),_._v("column_name1"),v("code",[_._v(")")]),_._v(" > 5;")])]),_._v(" "),v("h2",{attrs:{id:"修改数据的查询"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#修改数据的查询"}},[_._v("#")]),_._v(" 修改数据的查询")]),_._v(" "),v("h3",{attrs:{id:"insert-into-用于在表中插入新记录-行"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#insert-into-用于在表中插入新记录-行"}},[_._v("#")]),_._v(" "),v("strong",[_._v("INSERT INTO")]),_._v(": 用于在表中插入新记录/行")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("INSERT INTO")]),_._v(" table_name (column1, column2) "),v("code",[_._v("VALUES")]),_._v(" (value1, value2);")]),_._v(" "),v("li",[v("code",[_._v("INSERT INTO")]),_._v(" table_name "),v("code",[_._v("VALUES")]),_._v(" (value1, value2 …);")])]),_._v(" "),v("h3",{attrs:{id:"update-用于修改表中的现有记录-行"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#update-用于修改表中的现有记录-行"}},[_._v("#")]),_._v(" "),v("strong",[_._v("UPDATE")]),_._v(": 用于修改表中的现有记录/行")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("UPDATE")]),_._v(" table_name "),v("code",[_._v("SET")]),_._v(" column1 = value1, column2 = value2 "),v("code",[_._v("WHERE")]),_._v(" condition;")]),_._v(" "),v("li",[v("code",[_._v("UPDATE")]),_._v(" table_name "),v("code",[_._v("SET")]),_._v(" column_name = value;")])]),_._v(" "),v("h3",{attrs:{id:"delete-用于删除表中的现有记录-行"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#delete-用于删除表中的现有记录-行"}},[_._v("#")]),_._v(" "),v("strong",[_._v("DELETE")]),_._v(": 用于删除表中的现有记录/行")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("DELETE FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition;")]),_._v(" "),v("li",[v("code",[_._v("DELETE")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" table_name;")])]),_._v(" "),v("h2",{attrs:{id:"聚合查询"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#聚合查询"}},[_._v("#")]),_._v(" 聚合查询")]),_._v(" "),v("h3",{attrs:{id:"count-返回出现次数"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#count-返回出现次数"}},[_._v("#")]),_._v(" "),v("strong",[_._v("COUNT")]),_._v(": 返回出现次数")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT COUNT (DISTINCT")]),_._v(" column_name"),v("code",[_._v(")")]),_._v(";")])]),_._v(" "),v("h3",{attrs:{id:"min-and-max-返回所选列的最小-最大值"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#min-and-max-返回所选列的最小-最大值"}},[_._v("#")]),_._v(" "),v("strong",[_._v("MIN() and MAX()")]),_._v(": 返回所选列的最小/最大值")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT MIN (")]),_._v("column_names"),v("code",[_._v(") FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition;")]),_._v(" "),v("li",[v("code",[_._v("SELECT MAX (")]),_._v("column_names"),v("code",[_._v(") FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition;")])]),_._v(" "),v("h3",{attrs:{id:"avg-返回数字列的平均值"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#avg-返回数字列的平均值"}},[_._v("#")]),_._v(" "),v("strong",[_._v("AVG()")]),_._v(": 返回数字列的平均值")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT AVG (")]),_._v("column_name"),v("code",[_._v(") FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition;")])]),_._v(" "),v("h3",{attrs:{id:"sum-返回数值列的总和"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#sum-返回数值列的总和"}},[_._v("#")]),_._v(" "),v("strong",[_._v("SUM()")]),_._v(": 返回数值列的总和")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT SUM (")]),_._v("column_name"),v("code",[_._v(") FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition;")])]),_._v(" "),v("h2",{attrs:{id:"连接查询"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#连接查询"}},[_._v("#")]),_._v(" 连接查询")]),_._v(" "),v("h3",{attrs:{id:"inner-join-内连接-返回在两张表中具有匹配值的记录"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#inner-join-内连接-返回在两张表中具有匹配值的记录"}},[_._v("#")]),_._v(" "),v("strong",[_._v("INNER JOIN")]),_._v(": 内连接，返回在两张表中具有匹配值的记录")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" column_names "),v("code",[_._v("FROM")]),_._v(" table1 "),v("code",[_._v("INNER JOIN")]),_._v(" table2 "),v("code",[_._v("ON")]),_._v(" table1.column_name=table2.column_name;")]),_._v(" "),v("li",[v("code",[_._v("SELECT")]),_._v(" table1.column_name1, table2.column_name2, table3.column_name3 "),v("code",[_._v("FROM")]),_._v(" ((table1 "),v("code",[_._v("INNER JOIN")]),_._v(" table2 "),v("code",[_._v("ON")]),_._v(" relationship) "),v("code",[_._v("INNER JOIN")]),_._v(" table3 "),v("code",[_._v("ON")]),_._v(" relationship);")])]),_._v(" "),v("h3",{attrs:{id:"left-outer-join-左外连接-返回左表-table1-中的所有记录-以及右表中的匹配记录-table2"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#left-outer-join-左外连接-返回左表-table1-中的所有记录-以及右表中的匹配记录-table2"}},[_._v("#")]),_._v(" "),v("strong",[_._v("LEFT (OUTER) JOIN")]),_._v(": 左外连接，返回左表（table1）中的所有记录，以及右表中的匹配记录（table2）")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" column_names "),v("code",[_._v("FROM")]),_._v(" table1 "),v("code",[_._v("LEFT JOIN")]),_._v(" table2 "),v("code",[_._v("ON")]),_._v(" table1.column_name=table2.column_name;")])]),_._v(" "),v("h3",{attrs:{id:"right-outer-join-右外连接-返回右表-table2-中的所有记录-以及左表-table1-中匹配的记录"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#right-outer-join-右外连接-返回右表-table2-中的所有记录-以及左表-table1-中匹配的记录"}},[_._v("#")]),_._v(" "),v("strong",[_._v("RIGHT (OUTER) JOIN")]),_._v(": 右外连接，返回右表（table2）中的所有记录，以及左表（table1）中匹配的记录")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" column_names "),v("code",[_._v("FROM")]),_._v(" table1 "),v("code",[_._v("RIGHT JOIN")]),_._v(" table2 "),v("code",[_._v("ON")]),_._v(" table1.column_name=table2.column_name;")])]),_._v(" "),v("h3",{attrs:{id:"full-outer-join-全外连接-全连接是左右外连接的并集-连接表包含被连接的表的所有记录-如果缺少匹配的记录-以-null-填充。"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#full-outer-join-全外连接-全连接是左右外连接的并集-连接表包含被连接的表的所有记录-如果缺少匹配的记录-以-null-填充。"}},[_._v("#")]),_._v(" "),v("strong",[_._v("FULL (OUTER) JOIN")]),_._v(": 全外连接，全连接是左右外连接的并集. 连接表包含被连接的表的所有记录, 如果缺少匹配的记录, 以 NULL 填充。")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" column_names "),v("code",[_._v("FROM")]),_._v(" table1 "),v("code",[_._v("FULL OUTER JOIN")]),_._v(" table2 "),v("code",[_._v("ON")]),_._v(" table1.column_name=table2.column_name;")])]),_._v(" "),v("h3",{attrs:{id:"self-join-自连接-表自身连接"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#self-join-自连接-表自身连接"}},[_._v("#")]),_._v(" "),v("strong",[_._v("Self JOIN")]),_._v(": 自连接，表自身连接")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" column_names "),v("code",[_._v("FROM")]),_._v(" table1 T1, table1 T2 "),v("code",[_._v("WHERE")]),_._v(" condition;")])]),_._v(" "),v("h2",{attrs:{id:"视图查询"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#视图查询"}},[_._v("#")]),_._v(" 视图查询")]),_._v(" "),v("h3",{attrs:{id:"create-创建视图"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#create-创建视图"}},[_._v("#")]),_._v(" "),v("strong",[_._v("CREATE")]),_._v(": 创建视图")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("CREATE VIEW")]),_._v(" view_name "),v("code",[_._v("AS SELECT")]),_._v(" column1, column2 "),v("code",[_._v("FROM")]),_._v(" table_name "),v("code",[_._v("WHERE")]),_._v(" condition;")])]),_._v(" "),v("h3",{attrs:{id:"select-检索视图"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#select-检索视图"}},[_._v("#")]),_._v(" "),v("strong",[_._v("SELECT")]),_._v(": 检索视图")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("SELECT")]),_._v(" * "),v("code",[_._v("FROM")]),_._v(" view_name;")])]),_._v(" "),v("h3",{attrs:{id:"drop-删除视图"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#drop-删除视图"}},[_._v("#")]),_._v(" "),v("strong",[_._v("DROP")]),_._v(": 删除视图")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("DROP VIEW")]),_._v(" view_name;")])]),_._v(" "),v("h2",{attrs:{id:"修改表的查询"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#修改表的查询"}},[_._v("#")]),_._v(" 修改表的查询")]),_._v(" "),v("h3",{attrs:{id:"add-添加字段"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#add-添加字段"}},[_._v("#")]),_._v(" "),v("strong",[_._v("ADD")]),_._v(": 添加字段")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("ALTER TABLE")]),_._v(" table_name "),v("code",[_._v("ADD")]),_._v(" column_name column_definition;")])]),_._v(" "),v("h3",{attrs:{id:"modify-修改字段数据类型"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#modify-修改字段数据类型"}},[_._v("#")]),_._v(" "),v("strong",[_._v("MODIFY")]),_._v(": 修改字段数据类型")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("ALTER TABLE")]),_._v(" table_name "),v("code",[_._v("MODIFY")]),_._v(" column_name column_type;")])]),_._v(" "),v("h3",{attrs:{id:"drop-删除字段"}},[v("a",{staticClass:"header-anchor",attrs:{href:"#drop-删除字段"}},[_._v("#")]),_._v(" "),v("strong",[_._v("DROP")]),_._v(": 删除字段")]),_._v(" "),v("ul",[v("li",[v("code",[_._v("ALTER TABLE")]),_._v(" table_name "),v("code",[_._v("DROP COLUMN")]),_._v(" column_name;")])])])}),[],!1,null,null,null);v.default=o.exports}}]); \ No newline at end of file diff --git a/assets/js/17.afee0370.js b/assets/js/17.afee0370.js new file mode 100644 index 00000000..002591e3 --- /dev/null +++ b/assets/js/17.afee0370.js @@ -0,0 +1 @@ +(window.webpackJsonp=window.webpackJsonp||[]).push([[17],{354:function(t,r,e){"use strict";e.r(r);var a=e(4),s=Object(a.a)({},(function(){var t=this,r=t._self._c;return r("ContentSlotsDistributor",{attrs:{"slot-key":t.$parent.slotKey}},[r("h1",{attrs:{id:"关系型数据库综合知识"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#关系型数据库综合知识"}},[t._v("#")]),t._v(" 关系型数据库综合知识")]),t._v(" "),r("h2",{attrs:{id:"📖-内容"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#📖-内容"}},[t._v("#")]),t._v(" 📖 内容")]),t._v(" "),r("h3",{attrs:{id:"关系型数据库面试总结-💯"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#关系型数据库面试总结-💯"}},[t._v("#")]),t._v(" "),r("RouterLink",{attrs:{to:"/12.数据库/03.关系型数据库/01.综合/01.关系型数据库面试.html"}},[t._v("关系型数据库面试总结")]),t._v(" 💯")],1),t._v(" "),r("h3",{attrs:{id:"sql-语法基础特性"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#sql-语法基础特性"}},[t._v("#")]),t._v(" "),r("RouterLink",{attrs:{to:"/12.数据库/03.关系型数据库/01.综合/02.SQL语法基础特性.html"}},[t._v("SQL 语法基础特性")])],1),t._v(" "),r("h3",{attrs:{id:"sql-语法高级特性"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#sql-语法高级特性"}},[t._v("#")]),t._v(" "),r("RouterLink",{attrs:{to:"/12.数据库/03.关系型数据库/01.综合/03.SQL语法高级特性.html"}},[t._v("SQL 语法高级特性")])],1),t._v(" "),r("h3",{attrs:{id:"扩展-sql"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#扩展-sql"}},[t._v("#")]),t._v(" "),r("RouterLink",{attrs:{to:"/12.数据库/03.关系型数据库/01.综合/03.扩展SQL.html"}},[t._v("扩展 SQL")])],1),t._v(" "),r("h3",{attrs:{id:"sql-cheat-sheet"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#sql-cheat-sheet"}},[t._v("#")]),t._v(" "),r("RouterLink",{attrs:{to:"/12.数据库/03.关系型数据库/01.综合/99.SqlCheatSheet.html"}},[t._v("SQL Cheat Sheet")])],1),t._v(" "),r("h2",{attrs:{id:"📚-资料"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#📚-资料"}},[t._v("#")]),t._v(" 📚 资料")]),t._v(" "),r("ul",[r("li",[r("strong",[t._v("官方")]),t._v(" "),r("ul",[r("li",[r("a",{attrs:{href:"https://www.mysql.com/",target:"_blank",rel:"noopener noreferrer"}},[t._v("Mysql 官网"),r("OutboundLink")],1)]),t._v(" "),r("li",[r("a",{attrs:{href:"https://dev.mysql.com/doc/",target:"_blank",rel:"noopener noreferrer"}},[t._v("Mysql 官方文档"),r("OutboundLink")],1)]),t._v(" "),r("li",[r("a",{attrs:{href:"https://dev.mysql.com/doc/refman/8.0/en/mysql.html",target:"_blank",rel:"noopener noreferrer"}},[t._v("Mysql 官方文档之命令行客户端"),r("OutboundLink")],1)])])]),t._v(" "),r("li",[r("strong",[t._v("书籍")]),t._v(" "),r("ul",[r("li",[r("a",{attrs:{href:"https://item.jd.com/11220393.html",target:"_blank",rel:"noopener noreferrer"}},[t._v("《高性能 MySQL》"),r("OutboundLink")],1),t._v(" - Mysql 经典")]),t._v(" "),r("li",[r("a",{attrs:{href:"https://book.douban.com/subject/35167240/",target:"_blank",rel:"noopener noreferrer"}},[t._v("《SQL 必知必会》"),r("OutboundLink")],1),t._v(" - SQL 入门")])])]),t._v(" "),r("li",[r("strong",[t._v("教程")]),t._v(" "),r("ul",[r("li",[r("a",{attrs:{href:"http://www.runoob.com/mymysql-tutorial.html",target:"_blank",rel:"noopener noreferrer"}},[t._v("runoob.com MySQL 教程"),r("OutboundLink")],1),t._v(" - 入门级 SQL 教程")]),t._v(" "),r("li",[r("a",{attrs:{href:"https://github.com/jaywcjlove/mysql-tutorial",target:"_blank",rel:"noopener noreferrer"}},[t._v("mysql-tutorial"),r("OutboundLink")],1)])])]),t._v(" "),r("li",[r("strong",[t._v("更多资源")]),t._v(" "),r("ul",[r("li",[r("a",{attrs:{href:"https://github.com/jobbole/awesome-mysql-cn",target:"_blank",rel:"noopener noreferrer"}},[t._v("awesome-mysql"),r("OutboundLink")],1)])])])]),t._v(" "),r("h2",{attrs:{id:"🚪-传送"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#🚪-传送"}},[t._v("#")]),t._v(" 🚪 传送")]),t._v(" "),r("p",[t._v("◾ 💧 "),r("a",{attrs:{href:"https://dunwu.github.io/waterdrop/",target:"_blank",rel:"noopener noreferrer"}},[t._v("钝悟的 IT 知识图谱"),r("OutboundLink")],1),t._v(" ◾ 🎯 "),r("a",{attrs:{href:"https://dunwu.github.io/blog/",target:"_blank",rel:"noopener noreferrer"}},[t._v("钝悟的博客"),r("OutboundLink")],1),t._v(" ◾")])])}),[],!1,null,null,null);r.default=s.exports}}]); \ No newline at end of file diff --git a/assets/js/18.0eb469ef.js b/assets/js/18.0eb469ef.js new file mode 100644 index 00000000..e87b2ace --- /dev/null +++ b/assets/js/18.0eb469ef.js @@ -0,0 +1 @@ +(window.webpackJsonp=window.webpackJsonp||[]).push([[18],{355:function(t,a,s){"use strict";s.r(a);var r=s(4),e=Object(r.a)({},(function(){var t=this,a=t._self._c;return a("ContentSlotsDistributor",{attrs:{"slot-key":t.$parent.slotKey}},[a("h1",{attrs:{id:"mysql-应用指南"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#mysql-应用指南"}},[t._v("#")]),t._v(" Mysql 应用指南")]),t._v(" "),a("h2",{attrs:{id:"sql-执行过程"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#sql-执行过程"}},[t._v("#")]),t._v(" SQL 执行过程")]),t._v(" "),a("p",[t._v("学习 Mysql，最好是先从宏观上了解 Mysql 工作原理。")]),t._v(" "),a("blockquote",[a("p",[t._v("参考："),a("RouterLink",{attrs:{to:"/12.数据库/03.关系型数据库/02.Mysql/02.MySQL工作流.html"}},[t._v("Mysql 工作流")])],1)]),t._v(" "),a("h2",{attrs:{id:"存储引擎"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#存储引擎"}},[t._v("#")]),t._v(" 存储引擎")]),t._v(" "),a("p",[t._v("在文件系统中，Mysql 将每个数据库（也可以成为 schema）保存为数据目录下的一个子目录。创建表示，Mysql 会在数据库子目录下创建一个和表同名的 "),a("code",[t._v(".frm")]),t._v(" 文件保存表的定义。因为 Mysql 使用文件系统的目录和文件来保存数据库和表的定义，大小写敏感性和具体平台密切相关。Windows 中大小写不敏感；类 Unix 中大小写敏感。"),a("strong",[t._v("不同的存储引擎保存数据和索引的方式是不同的，但表的定义则是在 Mysql 服务层统一处理的。")])]),t._v(" "),a("h3",{attrs:{id:"选择存储引擎"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#选择存储引擎"}},[t._v("#")]),t._v(" 选择存储引擎")]),t._v(" "),a("h4",{attrs:{id:"mysql-内置的存储引擎"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#mysql-内置的存储引擎"}},[t._v("#")]),t._v(" Mysql 内置的存储引擎")]),t._v(" "),a("div",{staticClass:"language-shell extra-class"},[a("pre",{pre:!0,attrs:{class:"language-shell"}},[a("code",[t._v("mysql"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v(">")]),t._v(" SHOW ENGINES"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+\n"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Engine "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Support "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Comment "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Transactions "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" XA "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Savepoints "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+\n"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" FEDERATED "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Federated MySQL storage engine "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NULL "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NULL "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NULL "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" MEMORY "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" YES "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Hash based, stored "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("in")]),t._v(" memory, useful "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("for")]),t._v(" temporary tables "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" InnoDB "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" DEFAULT "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Supports transactions, row-level locking, and foreign keys "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" YES "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" YES "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" YES "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" PERFORMANCE_SCHEMA "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" YES "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Performance Schema "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" MyISAM "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" YES "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" MyISAM storage engine "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" MRG_MYISAM "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" YES "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Collection of identical MyISAM tables "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" BLACKHOLE "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" YES "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" /dev/null storage engine "),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),t._v("anything you "),a("span",{pre:!0,attrs:{class:"token function"}},[t._v("write")]),t._v(" to it disappears"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" CSV "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" YES "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" CSV storage engine "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n"),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" ARCHIVE "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" YES "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Archive storage engine "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" NO "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+\n"),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("9")]),t._v(" rows "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("in")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token builtin class-name"}},[t._v("set")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v("(")]),a("span",{pre:!0,attrs:{class:"token number"}},[t._v("0.00")]),t._v(" sec"),a("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(")")]),t._v("\n")])])]),a("ul",[a("li",[a("strong",[t._v("InnoDB")]),t._v(" - Mysql 的默认事务型存储引擎，并且提供了行级锁和外键的约束。性能不错且支持自动崩溃恢复。")]),t._v(" "),a("li",[a("strong",[t._v("MyISAM")]),t._v(" - Mysql 5.1 版本前的默认存储引擎。特性丰富但不支持事务，也不支持行级锁和外键，也没有崩溃恢复功能。")]),t._v(" "),a("li",[a("strong",[t._v("CSV")]),t._v(" - 可以将 CSV 文件作为 Mysql 的表来处理，但这种表不支持索引。")]),t._v(" "),a("li",[a("strong",[t._v("Memory")]),t._v(" - 适合快速访问数据，且数据不会被修改，重启丢失也没有关系。")]),t._v(" "),a("li",[a("strong",[t._v("NDB")]),t._v(" - 用于 Mysql 集群场景。")])]),t._v(" "),a("h4",{attrs:{id:"如何选择合适的存储引擎"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#如何选择合适的存储引擎"}},[t._v("#")]),t._v(" 如何选择合适的存储引擎")]),t._v(" "),a("p",[t._v("大多数情况下，InnoDB 都是正确的选择，除非需要用到 InnoDB 不具备的特性。")]),t._v(" "),a("p",[t._v("如果应用需要选择 InnoDB 以外的存储引擎，可以考虑以下因素：")]),t._v(" "),a("ul",[a("li",[t._v("事务：如果需要支持事务，InnoDB 是首选。如果不需要支持事务，且主要是 SELECT 和 INSERT 操作，MyISAM 是不错的选择。所以，如果 Mysql 部署方式为主备模式，并进行读写分离。那么可以这么做：主节点只支持写操作，默认引擎为 InnoDB；备节点只支持读操作，默认引擎为 MyISAM。")]),t._v(" "),a("li",[t._v("并发：MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。所以，InnoDB 并发性能更高。")]),t._v(" "),a("li",[t._v("外键：InnoDB 支持外键。")]),t._v(" "),a("li",[t._v("备份：InnoDB 支持在线热备份。")]),t._v(" "),a("li",[t._v("崩溃恢复：MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。")]),t._v(" "),a("li",[t._v("其它特性：MyISAM 支持压缩表和空间数据索引。")])]),t._v(" "),a("h4",{attrs:{id:"转换表的存储引擎"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#转换表的存储引擎"}},[t._v("#")]),t._v(" 转换表的存储引擎")]),t._v(" "),a("p",[t._v("下面的语句可以将 mytable 表的引擎修改为 InnoDB")]),t._v(" "),a("div",{staticClass:"language-sql extra-class"},[a("pre",{pre:!0,attrs:{class:"language-sql"}},[a("code",[a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ALTER")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("TABLE")]),t._v(" mytable "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("ENGINE")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),t._v(" "),a("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("InnoDB")]),t._v("\n")])])]),a("h3",{attrs:{id:"myisam"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#myisam"}},[t._v("#")]),t._v(" MyISAM")]),t._v(" "),a("p",[t._v("MyISAM 设计简单，数据以紧密格式存储。对于只读数据，或者表比较小、可以容忍修复操作，则依然可以使用 MyISAM。")]),t._v(" "),a("p",[t._v("MyISAM 引擎使用 B+Tree 作为索引结构，"),a("strong",[t._v("叶节点的 data 域存放的是数据记录的地址")]),t._v("。")]),t._v(" "),a("p",[t._v("MyISAM 提供了大量的特性，包括：全文索引、压缩表、空间函数等。但是，MyISAM 不支持事务和行级锁。并且 MyISAM 不支持崩溃后的安全恢复。")]),t._v(" "),a("h3",{attrs:{id:"innodb"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#innodb"}},[t._v("#")]),t._v(" InnoDB")]),t._v(" "),a("p",[t._v("InnoDB 是 MySQL 默认的事务型存储引擎，只有在需要 InnoDB 不支持的特性时，才考虑使用其它存储引擎。")]),t._v(" "),a("p",[t._v("然 InnoDB 也使用 B+Tree 作为索引结构，但具体实现方式却与 MyISAM 截然不同。MyISAM 索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。而"),a("strong",[t._v("在 InnoDB 中，表数据文件本身就是按 B+Tree 组织的一个索引结构")]),t._v("，这棵树的叶节点 data 域保存了完整的数据记录。这个"),a("strong",[t._v("索引的 key 是数据表的主键")]),t._v("，因此"),a("strong",[t._v("InnoDB 表数据文件本身就是主索引")]),t._v("。")]),t._v(" "),a("p",[t._v("InnoDB 采用 MVCC 来支持高并发，并且实现了四个标准的隔离级别。其默认级别是可重复读（REPEATABLE READ），并且通过间隙锁（next-key locking）防止幻读。")]),t._v(" "),a("p",[t._v("InnoDB 是基于聚簇索引建立的，与其他存储引擎有很大不同。在索引中保存了数据，从而避免直接读取磁盘，因此对查询性能有很大的提升。")]),t._v(" "),a("p",[t._v("内部做了很多优化，包括从磁盘读取数据时采用的可预测性读、能够加快读操作并且自动创建的自适应哈希索引、能够加速插入操作的插入缓冲区等。")]),t._v(" "),a("p",[t._v("支持真正的在线热备份。其它存储引擎不支持在线热备份，要获取一致性视图需要停止对所有表的写入，而在读写混合场景中，停止写入可能也意味着停止读取。")]),t._v(" "),a("h2",{attrs:{id:"数据类型"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#数据类型"}},[t._v("#")]),t._v(" 数据类型")]),t._v(" "),a("h3",{attrs:{id:"整型"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#整型"}},[t._v("#")]),t._v(" 整型")]),t._v(" "),a("p",[a("code",[t._v("TINYINT")]),t._v(", "),a("code",[t._v("SMALLINT")]),t._v(", "),a("code",[t._v("MEDIUMINT")]),t._v(", "),a("code",[t._v("INT")]),t._v(", "),a("code",[t._v("BIGINT")]),t._v(" 分别使用 "),a("code",[t._v("8")]),t._v(", "),a("code",[t._v("16")]),t._v(", "),a("code",[t._v("24")]),t._v(", "),a("code",[t._v("32")]),t._v(", "),a("code",[t._v("64")]),t._v(" 位存储空间，一般情况下越小的列越好。")]),t._v(" "),a("p",[a("strong",[a("code",[t._v("UNSIGNED")]),t._v(" 表示不允许负值，大致可以使正数的上限提高一倍")]),t._v("。")]),t._v(" "),a("p",[a("code",[t._v("INT(11)")]),t._v(" 中的数字只是规定了交互工具显示字符的个数，对于存储和计算来说是没有意义的。")]),t._v(" "),a("h3",{attrs:{id:"浮点型"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#浮点型"}},[t._v("#")]),t._v(" 浮点型")]),t._v(" "),a("p",[a("code",[t._v("FLOAT")]),t._v(" 和 "),a("code",[t._v("DOUBLE")]),t._v(" 为浮点类型。")]),t._v(" "),a("p",[a("code",[t._v("DECIMAL")]),t._v(" 类型主要用于精确计算，代价较高，应该尽量只在对小数进行精确计算时才使用 "),a("code",[t._v("DECIMAL")]),t._v(" ——例如存储财务数据。数据量比较大的时候，可以使用 "),a("code",[t._v("BIGINT")]),t._v(" 代替 "),a("code",[t._v("DECIMAL")]),t._v("。")]),t._v(" "),a("p",[a("code",[t._v("FLOAT")]),t._v("、"),a("code",[t._v("DOUBLE")]),t._v(" 和 "),a("code",[t._v("DECIMAL")]),t._v(" 都可以指定列宽，例如 "),a("code",[t._v("DECIMAL(18, 9)")]),t._v(" 表示总共 18 位，取 9 位存储小数部分，剩下 9 位存储整数部分。")]),t._v(" "),a("h3",{attrs:{id:"字符串"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#字符串"}},[t._v("#")]),t._v(" 字符串")]),t._v(" "),a("p",[t._v("主要有 "),a("code",[t._v("CHAR")]),t._v(" 和 "),a("code",[t._v("VARCHAR")]),t._v(" 两种类型，一种是定长的，一种是变长的。")]),t._v(" "),a("p",[a("strong",[a("code",[t._v("VARCHAR")]),t._v(" 这种变长类型能够节省空间，因为只需要存储必要的内容。但是在执行 UPDATE 时可能会使行变得比原来长")]),t._v("。当超出一个页所能容纳的大小时，就要执行额外的操作。MyISAM 会将行拆成不同的片段存储，而 InnoDB 则需要分裂页来使行放进页内。")]),t._v(" "),a("p",[a("code",[t._v("VARCHAR")]),t._v(" 会保留字符串末尾的空格，而 "),a("code",[t._v("CHAR")]),t._v(" 会删除。")]),t._v(" "),a("h3",{attrs:{id:"时间和日期"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#时间和日期"}},[t._v("#")]),t._v(" 时间和日期")]),t._v(" "),a("p",[t._v("MySQL 提供了两种相似的日期时间类型："),a("code",[t._v("DATATIME")]),t._v(" 和 "),a("code",[t._v("TIMESTAMP")]),t._v("。")]),t._v(" "),a("h4",{attrs:{id:"datatime"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#datatime"}},[t._v("#")]),t._v(" DATATIME")]),t._v(" "),a("p",[t._v("能够保存从 1001 年到 9999 年的日期和时间，精度为秒，使用 8 字节的存储空间。")]),t._v(" "),a("p",[t._v("它与时区无关。")]),t._v(" "),a("p",[t._v("默认情况下，MySQL 以一种可排序的、无歧义的格式显示 DATATIME 值，例如“2008-01-16 22:37:08”，这是 ANSI 标准定义的日期和时间表示方法。")]),t._v(" "),a("h4",{attrs:{id:"timestamp"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#timestamp"}},[t._v("#")]),t._v(" TIMESTAMP")]),t._v(" "),a("p",[t._v("和 UNIX 时间戳相同，保存从 1970 年 1 月 1 日午夜（格林威治时间）以来的秒数，使用 4 个字节，只能表示从 1970 年 到 2038 年。")]),t._v(" "),a("p",[t._v("它和时区有关，也就是说一个时间戳在不同的时区所代表的具体时间是不同的。")]),t._v(" "),a("p",[t._v("MySQL 提供了 FROM_UNIXTIME() 函数把 UNIX 时间戳转换为日期，并提供了 UNIX_TIMESTAMP() 函数把日期转换为 UNIX 时间戳。")]),t._v(" "),a("p",[t._v("默认情况下，如果插入时没有指定 TIMESTAMP 列的值，会将这个值设置为当前时间。")]),t._v(" "),a("p",[t._v("应该尽量使用 TIMESTAMP，因为它比 DATETIME 空间效率更高。")]),t._v(" "),a("h3",{attrs:{id:"blob-和-text"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#blob-和-text"}},[t._v("#")]),t._v(" BLOB 和 TEXT")]),t._v(" "),a("p",[a("code",[t._v("BLOB")]),t._v(" 和 "),a("code",[t._v("TEXT")]),t._v(" 都是为了存储大的数据而设计，前者存储二进制数据，后者存储字符串数据。")]),t._v(" "),a("p",[t._v("不能对 "),a("code",[t._v("BLOB")]),t._v(" 和 "),a("code",[t._v("TEXT")]),t._v(" 类型的全部内容进行排序、索引。")]),t._v(" "),a("h3",{attrs:{id:"枚举类型"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#枚举类型"}},[t._v("#")]),t._v(" 枚举类型")]),t._v(" "),a("p",[t._v("大多数情况下没有使用枚举类型的必要，其中一个缺点是：枚举的字符串列表是固定的，添加和删除字符串（枚举选项）必须使用"),a("code",[t._v("ALTER TABLE")]),t._v("（如果只只是在列表末尾追加元素，不需要重建表）。")]),t._v(" "),a("h3",{attrs:{id:"类型的选择"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#类型的选择"}},[t._v("#")]),t._v(" 类型的选择")]),t._v(" "),a("ul",[a("li",[a("p",[t._v("整数类型通常是标识列最好的选择，因为它们很快并且可以使用 "),a("code",[t._v("AUTO_INCREMENT")]),t._v("。")])]),t._v(" "),a("li",[a("p",[a("code",[t._v("ENUM")]),t._v(" 和 "),a("code",[t._v("SET")]),t._v(" 类型通常是一个糟糕的选择，应尽量避免。")])]),t._v(" "),a("li",[a("p",[t._v("应该尽量避免用字符串类型作为标识列，因为它们很消耗空间，并且通常比数字类型慢。对于 "),a("code",[t._v("MD5")]),t._v("、"),a("code",[t._v("SHA")]),t._v("、"),a("code",[t._v("UUID")]),t._v(" 这类随机字符串，由于比较随机，所以可能分布在很大的空间内，导致 "),a("code",[t._v("INSERT")]),t._v(" 以及一些 "),a("code",[t._v("SELECT")]),t._v(" 语句变得很慢。")]),t._v(" "),a("ul",[a("li",[t._v("如果存储 UUID ，应该移除 "),a("code",[t._v("-")]),t._v(" 符号；更好的做法是，用 "),a("code",[t._v("UNHEX()")]),t._v(" 函数转换 UUID 值为 16 字节的数字，并存储在一个 "),a("code",[t._v("BINARY(16)")]),t._v(" 的列中，检索时，可以通过 "),a("code",[t._v("HEX()")]),t._v(" 函数来格式化为 16 进制格式。")])])])]),t._v(" "),a("h2",{attrs:{id:"索引"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#索引"}},[t._v("#")]),t._v(" 索引")]),t._v(" "),a("blockquote",[a("p",[t._v("详见："),a("RouterLink",{attrs:{to:"/12.数据库/03.关系型数据库/02.Mysql/05.Mysql索引.html"}},[t._v("Mysql 索引")])],1)]),t._v(" "),a("h2",{attrs:{id:"锁"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#锁"}},[t._v("#")]),t._v(" 锁")]),t._v(" "),a("blockquote",[a("p",[t._v("详见："),a("RouterLink",{attrs:{to:"/12.数据库/03.关系型数据库/02.Mysql/04.Mysql锁.html"}},[t._v("Mysql 锁")])],1)]),t._v(" "),a("h2",{attrs:{id:"事务"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#事务"}},[t._v("#")]),t._v(" 事务")]),t._v(" "),a("blockquote",[a("p",[t._v("详见："),a("RouterLink",{attrs:{to:"/12.数据库/03.关系型数据库/02.Mysql/03.Mysql事务.html"}},[t._v("Mysql 事务")])],1)]),t._v(" "),a("h2",{attrs:{id:"性能优化"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#性能优化"}},[t._v("#")]),t._v(" 性能优化")]),t._v(" "),a("blockquote",[a("p",[t._v("详见："),a("RouterLink",{attrs:{to:"/12.数据库/03.关系型数据库/02.Mysql/06.Mysql性能优化.html"}},[t._v("Mysql 性能优化")])],1)]),t._v(" "),a("h2",{attrs:{id:"复制"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#复制"}},[t._v("#")]),t._v(" 复制")]),t._v(" "),a("h3",{attrs:{id:"主从复制"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#主从复制"}},[t._v("#")]),t._v(" 主从复制")]),t._v(" "),a("p",[t._v("Mysql 支持两种复制：基于行的复制和基于语句的复制。")]),t._v(" "),a("p",[t._v("这两种方式都是在主库上记录二进制日志，然后在从库重放日志的方式来实现异步的数据复制。这意味着：复制过程存在时延，这段时间内，主从数据可能不一致。")]),t._v(" "),a("p",[t._v("主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。")]),t._v(" "),a("ul",[a("li",[a("strong",[t._v("binlog 线程")]),t._v(" ：负责将主服务器上的数据更改写入二进制文件（binlog）中。")]),t._v(" "),a("li",[a("strong",[t._v("I/O 线程")]),t._v(" ：负责从主服务器上读取二进制日志文件，并写入从服务器的中继日志中。")]),t._v(" "),a("li",[a("strong",[t._v("SQL 线程")]),t._v(" ：负责读取中继日志并重放其中的 SQL 语句。")])]),t._v(" "),a("div",{attrs:{align:"center"}},[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/mysql/master-slave.png"}})]),t._v(" "),a("h3",{attrs:{id:"读写分离"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#读写分离"}},[t._v("#")]),t._v(" 读写分离")]),t._v(" "),a("p",[t._v("主服务器用来处理写操作以及实时性要求比较高的读操作，而从服务器用来处理读操作。")]),t._v(" "),a("p",[t._v("读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。")]),t._v(" "),a("p",[t._v("MySQL 读写分离能提高性能的原因在于：")]),t._v(" "),a("ul",[a("li",[t._v("主从服务器负责各自的读和写，极大程度缓解了锁的争用；")]),t._v(" "),a("li",[t._v("从服务器可以配置 MyISAM 引擎，提升查询性能以及节约系统开销；")]),t._v(" "),a("li",[t._v("增加冗余，提高可用性。")])]),t._v(" "),a("div",{attrs:{align:"center"}},[a("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/cs/database/mysql/master-slave-proxy.png"}})]),t._v(" "),a("h2",{attrs:{id:"参考资料"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#参考资料"}},[t._v("#")]),t._v(" 参考资料")]),t._v(" "),a("ul",[a("li",[a("a",{attrs:{href:"https://book.douban.com/subject/23008813/",target:"_blank",rel:"noopener noreferrer"}},[t._v("《高性能 MySQL》"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"https://www.jfox.info/20-tiao-mysql-xing-nen-you-hua-de-zui-jia-jing-yan.html",target:"_blank",rel:"noopener noreferrer"}},[t._v("20+ 条 MySQL 性能优化的最佳经验"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"https://stackoverflow.com/questions/788829/how-to-create-unique-row-id-in-sharded-databases",target:"_blank",rel:"noopener noreferrer"}},[t._v("How to create unique row ID in sharded databases?"),a("OutboundLink")],1)]),t._v(" "),a("li",[a("a",{attrs:{href:"http://geekswithblogs.net/shaunxu/archive/2012/01/07/sql-azure-federation-ndash-introduction.aspx",target:"_blank",rel:"noopener noreferrer"}},[t._v("SQL Azure Federation – Introduction"),a("OutboundLink")],1)])]),t._v(" "),a("h2",{attrs:{id:"传送门"}},[a("a",{staticClass:"header-anchor",attrs:{href:"#传送门"}},[t._v("#")]),t._v(" 传送门")]),t._v(" "),a("p",[t._v("◾ 💧 "),a("a",{attrs:{href:"https://dunwu.github.io/waterdrop/",target:"_blank",rel:"noopener noreferrer"}},[t._v("钝悟的 IT 知识图谱"),a("OutboundLink")],1),t._v(" ◾ 🎯 "),a("a",{attrs:{href:"https://dunwu.github.io/blog/",target:"_blank",rel:"noopener noreferrer"}},[t._v("钝悟的博客"),a("OutboundLink")],1),t._v(" ◾")])])}),[],!1,null,null,null);a.default=e.exports}}]); \ No newline at end of file diff --git a/assets/js/19.a32eb894.js b/assets/js/19.a32eb894.js new file mode 100644 index 00000000..cbd5fc48 --- /dev/null +++ b/assets/js/19.a32eb894.js @@ -0,0 +1 @@ +(window.webpackJsonp=window.webpackJsonp||[]).push([[19],{356:function(t,r,s){"use strict";s.r(r);var a=s(4),e=Object(a.a)({},(function(){var t=this,r=t._self._c;return r("ContentSlotsDistributor",{attrs:{"slot-key":t.$parent.slotKey}},[r("h1",{attrs:{id:"mysql-工作流"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#mysql-工作流"}},[t._v("#")]),t._v(" MySQL 工作流")]),t._v(" "),r("h2",{attrs:{id:"基础架构"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#基础架构"}},[t._v("#")]),t._v(" 基础架构")]),t._v(" "),r("p",[t._v("大体来说，MySQL 可以分为 Server 层和存储引擎层两部分。")]),t._v(" "),r("p",[r("strong",[t._v("Server 层包括连接器、查询缓存、分析器、优化器、执行器等")]),t._v("，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。")]),t._v(" "),r("p",[r("strong",[t._v("存储引擎层负责数据的存储和提取")]),t._v("。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。")]),t._v(" "),r("p",[r("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/snap/20200227201908.jpg",alt:"img"}})]),t._v(" "),r("h2",{attrs:{id:"查询过程"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#查询过程"}},[t._v("#")]),t._v(" 查询过程")]),t._v(" "),r("p",[t._v("SQL 语句在 MySQL 中是如何执行的？")]),t._v(" "),r("p",[t._v("MySQL 整个查询执行过程，总的来说分为 6 个步骤，分别对应 6 个组件：")]),t._v(" "),r("ol",[r("li",[t._v("连接器：客户端和 MySQL 服务器建立连接；连接器负责跟客户端建立连接、获取权限、维持和管理连接。")]),t._v(" "),r("li",[t._v("MySQL 服务器首先检查查询缓存，如果命中缓存，则立刻返回结果。否则进入下一阶段。")]),t._v(" "),r("li",[t._v("MySQL 服务器进行 SQL 分析：语法分析、词法分析。")]),t._v(" "),r("li",[t._v("MySQL 服务器用优化器生成对应的执行计划。")]),t._v(" "),r("li",[t._v("MySQL 服务器根据执行计划，调用存储引擎的 API 来执行查询。")]),t._v(" "),r("li",[t._v("MySQL 服务器将结果返回给客户端，同时缓存查询结果。")])]),t._v(" "),r("h3",{attrs:{id:"一-连接器"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#一-连接器"}},[t._v("#")]),t._v(" （一）连接器")]),t._v(" "),r("p",[t._v("使用 MySQL 第一步自然是要连接数据库。"),r("strong",[t._v("连接器负责跟客户端建立连接、获取权限、维持和管理连接")]),t._v("。")]),t._v(" "),r("p",[t._v("MySQL 客户端/服务端通信是"),r("strong",[t._v("半双工模式")]),t._v("：即任一时刻，要么是服务端向客户端发送数据，要么是客户端向服务器发送数据。客户端用一个单独的数据包将查询请求发送给服务器，所以当查询语句很长的时候，需要设置"),r("code",[t._v("max_allowed_packet")]),t._v("参数。但是需要注意的是，如果查询实在是太大，服务端会拒绝接收更多数据并抛出异常。")]),t._v(" "),r("p",[t._v("MySQL 客户端连接命令："),r("code",[t._v("mysql -h<主机> -P<端口> -u<用户名> -p<密码>")]),t._v("。如果没有显式指定密码，会要求输入密码才能访问。")]),t._v(" "),r("p",[t._v("连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 "),r("code",[t._v("show processlist")]),t._v(" 命令中看到它。客户端如果太长时间没动静，连接器就会自动将它断开。"),r("strong",[t._v("客户端连接维持时间是由参数 "),r("code",[t._v("wait_timeout")]),t._v(" 控制的，默认值是 8 小时")]),t._v("。如果在连接被断开之后，客户端再次发送请求的话，就会收到一个错误提醒： "),r("code",[t._v("Lost connection to MySQL server during query")]),t._v("。这时候如果你要继续，就需要重连，然后再执行请求了。")]),t._v(" "),r("p",[t._v("建立连接的过程通常是比较复杂的，建议在使用中要尽量减少建立连接的动作，也就是尽量使用长连接。为了在程序中提高数据库连接的服用了，一般会使用数据库连接池来维护管理。")]),t._v(" "),r("p",[t._v("但是全部使用长连接后，你可能会发现，有些时候 MySQL 占用内存涨得特别快，这是因为 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的。这些资源会在连接断开的时候才释放。所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是 MySQL 异常重启了。")]),t._v(" "),r("p",[t._v("怎么解决这个问题呢？你可以考虑以下两种方案。")]),t._v(" "),r("ul",[r("li",[r("strong",[t._v("定期断开长连接")]),t._v("。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。")]),t._v(" "),r("li",[t._v("如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行 "),r("code",[t._v("mysql_reset_connection")]),t._v(" 来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。")])]),t._v(" "),r("h3",{attrs:{id:"二-查询缓存"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#二-查询缓存"}},[t._v("#")]),t._v(" （二）查询缓存")]),t._v(" "),r("blockquote",[r("p",[r("strong",[t._v("不建议使用数据库缓存，因为往往弊大于利")]),t._v("。")])]),t._v(" "),r("p",[t._v("解析一个查询语句前，如果查询缓存是打开的，那么 MySQL 会检查这个查询语句是否命中查询缓存中的数据。如果当前查询恰好命中查询缓存，在检查一次用户权限后直接返回缓存中的结果。这种情况下，查询不会被解析，也不会生成执行计划，更不会执行。")]),t._v(" "),r("p",[t._v("MySQL 将缓存存放在一个引用表（不要理解成"),r("code",[t._v("table")]),t._v("，可以认为是类似于"),r("code",[t._v("HashMap")]),t._v("的数据结构），通过一个哈希值索引，这个哈希值通过查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息计算得来。所以两个查询在任何字符上的不同（例如：空格、注释），都会导致缓存不会命中。")]),t._v(" "),r("p",[r("strong",[t._v("如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql 库中的系统表，其查询结果都不会被缓存")]),t._v("。比如函数"),r("code",[t._v("NOW()")]),t._v("或者"),r("code",[t._v("CURRENT_DATE()")]),t._v("会因为不同的查询时间，返回不同的查询结果，再比如包含"),r("code",[t._v("CURRENT_USER")]),t._v("或者"),r("code",[t._v("CONNECION_ID()")]),t._v("的查询语句会因为不同的用户而返回不同的结果，将这样的查询结果缓存起来没有任何的意义。")]),t._v(" "),r("p",[r("strong",[t._v("不建议使用数据库缓存，因为往往弊大于利")]),t._v("。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。比如，一个系统配置表，那这张表上的查询才适合使用查询缓存。")]),t._v(" "),r("p",[t._v("好在 MySQL 也提供了这种“按需使用”的方式。你可以将参数 "),r("code",[t._v("query_cache_type")]),t._v(" 设置成 "),r("code",[t._v("DEMAND")]),t._v("，这样对于默认的 SQL 语句都不使用查询缓存。而对于你确定要使用查询缓存的语句，可以用 "),r("code",[t._v("SQL_CACHE")]),t._v(" 显式指定，像下面这个语句一样：")]),t._v(" "),r("div",{staticClass:"language-sql extra-class"},[r("pre",{pre:!0,attrs:{class:"language-sql"}},[r("code",[r("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("select")]),t._v(" SQL_CACHE "),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" "),r("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("from")]),t._v(" T "),r("span",{pre:!0,attrs:{class:"token keyword"}},[t._v("where")]),t._v(" ID"),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("=")]),r("span",{pre:!0,attrs:{class:"token number"}},[t._v("10")]),r("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n")])])]),r("blockquote",[r("p",[t._v("注意：MySQL 8.0 版本直接将查询缓存的整块功能删掉了。")])]),t._v(" "),r("h3",{attrs:{id:"三-语法分析"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#三-语法分析"}},[t._v("#")]),t._v(" （三）语法分析")]),t._v(" "),r("p",[t._v("如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL 需要知道你要做什么，因此需要对 SQL 语句做解析。MySQL 通过关键字对 SQL 语句进行解析，并生成一颗对应的语法解析树。这个过程中，分析器主要通过语法规则来验证和解析。比如 SQL 中是否使用了错误的关键字或者关键字的顺序是否正确等等。预处理则会根据 MySQL 规则进一步检查解析树是否合法。比如检查要查询的数据表和数据列是否存在等等。")]),t._v(" "),r("ul",[r("li",[t._v("分析器先会先做“"),r("strong",[t._v("词法分析")]),t._v('”。你输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么，代表什么。MySQL 从你输入的"select"这个关键字识别出来，这是一个查询语句。它也要把字符串“T”识别成“表名 T”，把字符串“ID”识别成“列 ID”。')]),t._v(" "),r("li",[t._v("接下来，要做“"),r("strong",[t._v("语法分析")]),t._v("”。根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。如果你的语句不对，就会收到“You have an error in your SQL syntax”的错误提醒，比如下面这个语句 select 少打了开头的字母“s”。")])]),t._v(" "),r("h3",{attrs:{id:"四-查询优化"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#四-查询优化"}},[t._v("#")]),t._v(" （四）查询优化")]),t._v(" "),r("p",[t._v("经过了分析器，MySQL 就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。")]),t._v(" "),r("p",[t._v("经过前面的步骤生成的语法树被认为是合法的了，并且由优化器将其转化成执行计划。多数情况下，一条查询可以有很多种执行方式，最后都返回相应的结果。优化器的作用就是找到这其中最好的执行计划。")]),t._v(" "),r("p",[t._v("MySQL 使用基于成本的优化器，它尝试预测一个查询使用某种执行计划时的成本，并选择其中成本最小的一个。在 MySQL 可以通过查询当前会话的 "),r("code",[t._v("last_query_cost")]),t._v(" 的值来得到其计算当前查询的成本。")]),t._v(" "),r("div",{staticClass:"language-ruby extra-class"},[r("pre",{pre:!0,attrs:{class:"language-ruby"}},[r("code",[t._v("mysql"),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v(">")]),t._v(" select "),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("*")]),t._v(" from t_message limit "),r("span",{pre:!0,attrs:{class:"token number"}},[t._v("10")]),r("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("...")]),t._v("省略结果集\n\nmysql"),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v(">")]),t._v(" show status like "),r("span",{pre:!0,attrs:{class:"token string-literal"}},[r("span",{pre:!0,attrs:{class:"token string"}},[t._v("'last_query_cost'")])]),r("span",{pre:!0,attrs:{class:"token punctuation"}},[t._v(";")]),t._v("\n"),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),t._v("\n"),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Variable_name "),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Value "),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n"),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),t._v("\n"),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" Last_query_cost "),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v(" "),r("span",{pre:!0,attrs:{class:"token number"}},[t._v("6391.799000")]),t._v(" "),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("|")]),t._v("\n"),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("-")]),r("span",{pre:!0,attrs:{class:"token operator"}},[t._v("+")]),t._v("\n")])])]),r("p",[t._v("示例中的结果表示优化器认为大概需要做 6391 个数据页的随机查找才能完成上面的查询。这个结果是根据一些列的统计信息计算得来的，这些统计信息包括：每张表或者索引的页面个数、索引的基数、索引和数据行的长度、索引的分布情况等等。")]),t._v(" "),r("p",[t._v("有非常多的原因会导致 MySQL 选择错误的执行计划，比如统计信息不准确、不会考虑不受其控制的操作成本（用户自定义函数、存储过程）、MySQL 认为的最优跟我们想的不一样（我们希望执行时间尽可能短，但 MySQL 值选择它认为成本小的，但成本小并不意味着执行时间短）等等。")]),t._v(" "),r("p",[t._v("MySQL 的查询优化器是一个非常复杂的部件，它使用了非常多的优化策略来生成一个最优的执行计划：")]),t._v(" "),r("ul",[r("li",[t._v("重新定义表的关联顺序（多张表关联查询时，并不一定按照 SQL 中指定的顺序进行，但有一些技巧可以指定关联顺序）")]),t._v(" "),r("li",[t._v("优化"),r("code",[t._v("MIN()")]),t._v("和"),r("code",[t._v("MAX()")]),t._v("函数（找某列的最小值，如果该列有索引，只需要查找 B+Tree 索引最左端，反之则可以找到最大值，具体原理见下文）")]),t._v(" "),r("li",[t._v("提前终止查询（比如：使用 Limit 时，查找到满足数量的结果集后会立即终止查询）")]),t._v(" "),r("li",[t._v("优化排序（在老版本 MySQL 会使用两次传输排序，即先读取行指针和需要排序的字段在内存中对其排序，然后再根据排序结果去读取数据行，而新版本采用的是单次传输排序，也就是一次读取所有的数据行，然后根据给定的列排序。对于 I/O 密集型应用，效率会高很多）")])]),t._v(" "),r("p",[t._v("随着 MySQL 的不断发展，优化器使用的优化策略也在不断的进化，这里仅仅介绍几个非常常用且容易理解的优化策略，其他的优化策略，大家自行查阅吧。")]),t._v(" "),r("h3",{attrs:{id:"五-查询执行引擎"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#五-查询执行引擎"}},[t._v("#")]),t._v(" （五）查询执行引擎")]),t._v(" "),r("p",[t._v("在完成解析和优化阶段以后，MySQL 会生成对应的执行计划，查询执行引擎根据执行计划给出的指令逐步执行得出结果。整个执行过程的大部分操作均是通过调用存储引擎实现的接口来完成，这些接口被称为"),r("code",[t._v("handler API")]),t._v("。查询过程中的每一张表由一个"),r("code",[t._v("handler")]),t._v("实例表示。实际上，MySQL 在查询优化阶段就为每一张表创建了一个"),r("code",[t._v("handler")]),t._v("实例，优化器可以根据这些实例的接口来获取表的相关信息，包括表的所有列名、索引统计信息等。存储引擎接口提供了非常丰富的功能，但其底层仅有几十个接口，这些接口像搭积木一样完成了一次查询的大部分操作。")]),t._v(" "),r("h3",{attrs:{id:"六-返回结果"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#六-返回结果"}},[t._v("#")]),t._v(" （六）返回结果")]),t._v(" "),r("p",[t._v("查询过程的最后一个阶段就是将结果返回给客户端。即使查询不到数据，MySQL 仍然会返回这个查询的相关信息，比如该查询影响到的行数以及执行时间等等。")]),t._v(" "),r("p",[t._v("如果查询缓存被打开且这个查询可以被缓存，MySQL 也会将结果存放到缓存中。")]),t._v(" "),r("p",[t._v("结果集返回客户端是一个增量且逐步返回的过程。有可能 MySQL 在生成第一条结果时，就开始向客户端逐步返回结果集了。这样服务端就无须存储太多结果而消耗过多内存，也可以让客户端第一时间获得返回结果。需要注意的是，结果集中的每一行都会以一个满足 ① 中所描述的通信协议的数据包发送，再通过 TCP 协议进行传输，在传输过程中，可能对 MySQL 的数据包进行缓存然后批量发送。")]),t._v(" "),r("h2",{attrs:{id:"更新过程"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#更新过程"}},[t._v("#")]),t._v(" 更新过程")]),t._v(" "),r("p",[t._v("MySQL 更新过程和 MySQL 查询过程类似，也会将流程走一遍。不一样的是："),r("strong",[t._v("更新流程还涉及两个重要的日志模块，：redo log（重做日志）和 binlog（归档日志）")]),t._v("。")]),t._v(" "),r("h3",{attrs:{id:"redo-log"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#redo-log"}},[t._v("#")]),t._v(" redo log")]),t._v(" "),r("p",[r("strong",[t._v("redo log 是 InnoDB 引擎特有的日志")]),t._v("。"),r("strong",[t._v("redo log 即重做日志")]),t._v("。redo log 是物理日志，记录的是“在某个数据页上做了什么修改”。")]),t._v(" "),r("p",[r("strong",[t._v("redo log 是基于 WAL 技术")]),t._v("。WAL 的全称是 "),r("strong",[t._v("Write-Ahead Logging")]),t._v("，它的关键点就是"),r("strong",[t._v("先写日志，再写磁盘")]),t._v("。具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log 里，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。")]),t._v(" "),r("p",[t._v("InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写。")]),t._v(" "),r("p",[r("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/snap/20200630180342.png",alt:"img"}})]),t._v(" "),r("p",[t._v("有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为"),r("strong",[t._v("crash-safe")]),t._v("。")]),t._v(" "),r("h3",{attrs:{id:"bin-log"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#bin-log"}},[t._v("#")]),t._v(" bin log")]),t._v(" "),r("p",[r("strong",[t._v("bin log 即归档日志")]),t._v("。binlog 是逻辑日志，记录的是这个语句的原始逻辑。")]),t._v(" "),r("p",[t._v("binlog 是可以追加写入的，即写到一定大小后会切换到下一个，并不会覆盖以前的日志。")]),t._v(" "),r("p",[r("strong",[t._v("binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用")]),t._v("。")]),t._v(" "),r("p",[r("code",[t._v("sync_binlog")]),t._v(" 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。")]),t._v(" "),r("h3",{attrs:{id:"redo-log-vs-bin-log"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#redo-log-vs-bin-log"}},[t._v("#")]),t._v(" redo log vs. bin log")]),t._v(" "),r("p",[t._v("这两种日志有以下三点不同。")]),t._v(" "),r("ul",[r("li",[t._v("redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。")]),t._v(" "),r("li",[t._v("redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。")]),t._v(" "),r("li",[t._v("redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。")])]),t._v(" "),r("p",[t._v("有了对这两个日志的概念性理解，我们再来看执行器和 InnoDB 引擎在执行这个简单的 update 语句时的内部流程。")]),t._v(" "),r("ol",[r("li",[t._v("执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。")]),t._v(" "),r("li",[t._v("执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。")]),t._v(" "),r("li",[t._v("引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。")]),t._v(" "),r("li",[t._v("执行器生成这个操作的 binlog，并把 binlog 写入磁盘。")]),t._v(" "),r("li",[t._v("执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。")])]),t._v(" "),r("p",[t._v("这里我给出这个 update 语句的执行流程图，图中浅色框表示是在 InnoDB 内部执行的，深色框表示是在执行器中执行的。")]),t._v(" "),r("p",[r("img",{attrs:{src:"https://raw.githubusercontent.com/dunwu/images/dev/snap/20200714133806.png",alt:"img"}})]),t._v(" "),r("h3",{attrs:{id:"两阶段提交"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#两阶段提交"}},[t._v("#")]),t._v(" 两阶段提交")]),t._v(" "),r("p",[t._v('redo log 的写入拆成了两个步骤：prepare 和 commit，这就是"两阶段提交"。为什么日志需要“两阶段提交”。')]),t._v(" "),r("p",[t._v("由于 redo log 和 binlog 是两个独立的逻辑，如果不用两阶段提交，要么就是先写完 redo log 再写 binlog，或者采用反过来的顺序。我们看看这两种方式会有什么问题。")]),t._v(" "),r("ul",[r("li",[r("strong",[t._v("先写 redo log 后写 binlog")]),t._v("。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于我们前面说过的，redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。\n但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。\n然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。")]),t._v(" "),r("li",[r("strong",[t._v("先写 binlog 后写 redo log")]),t._v("。如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1”这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同。")])]),t._v(" "),r("p",[t._v("可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。")]),t._v(" "),r("h2",{attrs:{id:"参考资料"}},[r("a",{staticClass:"header-anchor",attrs:{href:"#参考资料"}},[t._v("#")]),t._v(" 参考资料")]),t._v(" "),r("ul",[r("li",[r("a",{attrs:{href:"https://book.douban.com/subject/23008813/",target:"_blank",rel:"noopener noreferrer"}},[t._v("《高性能 MySQL》"),r("OutboundLink")],1)]),t._v(" "),r("li",[r("a",{attrs:{href:"https://time.geekbang.org/column/intro/139",target:"_blank",rel:"noopener noreferrer"}},[t._v("MySQL 实战 45 讲"),r("OutboundLink")],1)])])])}),[],!1,null,null,null);r.default=e.exports}}]); \ No newline at end of file diff --git a/assets/js/2.da1ec370.js b/assets/js/2.da1ec370.js new file mode 100644 index 00000000..fc249919 --- /dev/null +++ b/assets/js/2.da1ec370.js @@ -0,0 +1,14 @@ +(window.webpackJsonp=window.webpackJsonp||[]).push([[2],Array(257).concat([function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){(function(t){var r; +/** + * @license + * Lodash + * Copyright OpenJS Foundation and other contributors + * Released under MIT license + * Based on Underscore.js 1.8.3 + * Copyright Jeremy Ashkenas, DocumentCloud and Investigative Reporters & Editors + */(function(){var i="Expected a function",o="__lodash_placeholder__",s=[["ary",128],["bind",1],["bindKey",2],["curry",8],["curryRight",16],["flip",512],["partial",32],["partialRight",64],["rearg",256]],a="[object Arguments]",u="[object Array]",l="[object Boolean]",c="[object Date]",h="[object Error]",f="[object Function]",p="[object GeneratorFunction]",g="[object Map]",d="[object Number]",v="[object Object]",m="[object RegExp]",y="[object Set]",_="[object String]",b="[object Symbol]",w="[object WeakMap]",k="[object ArrayBuffer]",x="[object DataView]",P="[object Float32Array]",C="[object Float64Array]",T="[object Int8Array]",S="[object Int16Array]",L="[object Int32Array]",A="[object Uint8Array]",B="[object Uint16Array]",O="[object Uint32Array]",M=/\b__p \+= '';/g,E=/\b(__p \+=) '' \+/g,I=/(__e\(.*?\)|\b__t\)) \+\n'';/g,D=/&(?:amp|lt|gt|quot|#39);/g,$=/[&<>"']/g,j=RegExp(D.source),Y=RegExp($.source),X=/<%-([\s\S]+?)%>/g,N=/<%([\s\S]+?)%>/g,z=/<%=([\s\S]+?)%>/g,R=/\.|\[(?:[^[\]]*|(["'])(?:(?!\1)[^\\]|\\.)*?\1)\]/,H=/^\w*$/,U=/[^.[\]]+|\[(?:(-?\d+(?:\.\d+)?)|(["'])((?:(?!\2)[^\\]|\\.)*?)\2)\]|(?=(?:\.|\[\])(?:\.|\[\]|$))/g,F=/[\\^$.*+?()[\]{}|]/g,W=RegExp(F.source),q=/^\s+/,G=/\s/,K=/\{(?:\n\/\* \[wrapped with .+\] \*\/)?\n?/,Q=/\{\n\/\* \[wrapped with (.+)\] \*/,J=/,? & /,Z=/[^\x00-\x2f\x3a-\x40\x5b-\x60\x7b-\x7f]+/g,V=/[()=,{}\[\]\/\s]/,tt=/\\(\\)?/g,et=/\$\{([^\\}]*(?:\\.[^\\}]*)*)\}/g,nt=/\w*$/,rt=/^[-+]0x[0-9a-f]+$/i,it=/^0b[01]+$/i,ot=/^\[object .+?Constructor\]$/,st=/^0o[0-7]+$/i,at=/^(?:0|[1-9]\d*)$/,ut=/[\xc0-\xd6\xd8-\xf6\xf8-\xff\u0100-\u017f]/g,lt=/($^)/,ct=/['\n\r\u2028\u2029\\]/g,ht="\\u0300-\\u036f\\ufe20-\\ufe2f\\u20d0-\\u20ff",ft="\\xac\\xb1\\xd7\\xf7\\x00-\\x2f\\x3a-\\x40\\x5b-\\x60\\x7b-\\xbf\\u2000-\\u206f \\t\\x0b\\f\\xa0\\ufeff\\n\\r\\u2028\\u2029\\u1680\\u180e\\u2000\\u2001\\u2002\\u2003\\u2004\\u2005\\u2006\\u2007\\u2008\\u2009\\u200a\\u202f\\u205f\\u3000",pt="[\\ud800-\\udfff]",gt="["+ft+"]",dt="["+ht+"]",vt="\\d+",mt="[\\u2700-\\u27bf]",yt="[a-z\\xdf-\\xf6\\xf8-\\xff]",_t="[^\\ud800-\\udfff"+ft+vt+"\\u2700-\\u27bfa-z\\xdf-\\xf6\\xf8-\\xffA-Z\\xc0-\\xd6\\xd8-\\xde]",bt="\\ud83c[\\udffb-\\udfff]",wt="[^\\ud800-\\udfff]",kt="(?:\\ud83c[\\udde6-\\uddff]){2}",xt="[\\ud800-\\udbff][\\udc00-\\udfff]",Pt="[A-Z\\xc0-\\xd6\\xd8-\\xde]",Ct="(?:"+yt+"|"+_t+")",Tt="(?:"+Pt+"|"+_t+")",St="(?:"+dt+"|"+bt+")"+"?",Lt="[\\ufe0e\\ufe0f]?"+St+("(?:\\u200d(?:"+[wt,kt,xt].join("|")+")[\\ufe0e\\ufe0f]?"+St+")*"),At="(?:"+[mt,kt,xt].join("|")+")"+Lt,Bt="(?:"+[wt+dt+"?",dt,kt,xt,pt].join("|")+")",Ot=RegExp("['’]","g"),Mt=RegExp(dt,"g"),Et=RegExp(bt+"(?="+bt+")|"+Bt+Lt,"g"),It=RegExp([Pt+"?"+yt+"+(?:['’](?:d|ll|m|re|s|t|ve))?(?="+[gt,Pt,"$"].join("|")+")",Tt+"+(?:['’](?:D|LL|M|RE|S|T|VE))?(?="+[gt,Pt+Ct,"$"].join("|")+")",Pt+"?"+Ct+"+(?:['’](?:d|ll|m|re|s|t|ve))?",Pt+"+(?:['’](?:D|LL|M|RE|S|T|VE))?","\\d*(?:1ST|2ND|3RD|(?![123])\\dTH)(?=\\b|[a-z_])","\\d*(?:1st|2nd|3rd|(?![123])\\dth)(?=\\b|[A-Z_])",vt,At].join("|"),"g"),Dt=RegExp("[\\u200d\\ud800-\\udfff"+ht+"\\ufe0e\\ufe0f]"),$t=/[a-z][A-Z]|[A-Z]{2}[a-z]|[0-9][a-zA-Z]|[a-zA-Z][0-9]|[^a-zA-Z0-9 ]/,jt=["Array","Buffer","DataView","Date","Error","Float32Array","Float64Array","Function","Int8Array","Int16Array","Int32Array","Map","Math","Object","Promise","RegExp","Set","String","Symbol","TypeError","Uint8Array","Uint8ClampedArray","Uint16Array","Uint32Array","WeakMap","_","clearTimeout","isFinite","parseInt","setTimeout"],Yt=-1,Xt={};Xt[P]=Xt[C]=Xt[T]=Xt[S]=Xt[L]=Xt[A]=Xt["[object Uint8ClampedArray]"]=Xt[B]=Xt[O]=!0,Xt[a]=Xt[u]=Xt[k]=Xt[l]=Xt[x]=Xt[c]=Xt[h]=Xt[f]=Xt[g]=Xt[d]=Xt[v]=Xt[m]=Xt[y]=Xt[_]=Xt[w]=!1;var Nt={};Nt[a]=Nt[u]=Nt[k]=Nt[x]=Nt[l]=Nt[c]=Nt[P]=Nt[C]=Nt[T]=Nt[S]=Nt[L]=Nt[g]=Nt[d]=Nt[v]=Nt[m]=Nt[y]=Nt[_]=Nt[b]=Nt[A]=Nt["[object Uint8ClampedArray]"]=Nt[B]=Nt[O]=!0,Nt[h]=Nt[f]=Nt[w]=!1;var zt={"\\":"\\","'":"'","\n":"n","\r":"r","\u2028":"u2028","\u2029":"u2029"},Rt=parseFloat,Ht=parseInt,Ut="object"==typeof global&&global&&global.Object===Object&&global,Ft="object"==typeof self&&self&&self.Object===Object&&self,Wt=Ut||Ft||Function("return this")(),qt=e&&!e.nodeType&&e,Gt=qt&&"object"==typeof t&&t&&!t.nodeType&&t,Kt=Gt&&Gt.exports===qt,Qt=Kt&&Ut.process,Jt=function(){try{var t=Gt&&Gt.require&&Gt.require("util").types;return t||Qt&&Qt.binding&&Qt.binding("util")}catch(t){}}(),Zt=Jt&&Jt.isArrayBuffer,Vt=Jt&&Jt.isDate,te=Jt&&Jt.isMap,ee=Jt&&Jt.isRegExp,ne=Jt&&Jt.isSet,re=Jt&&Jt.isTypedArray;function ie(t,e,n){switch(n.length){case 0:return t.call(e);case 1:return t.call(e,n[0]);case 2:return t.call(e,n[0],n[1]);case 3:return t.call(e,n[0],n[1],n[2])}return t.apply(e,n)}function oe(t,e,n,r){for(var i=-1,o=null==t?0:t.length;++i-1}function he(t,e,n){for(var r=-1,i=null==t?0:t.length;++r-1;);return n}function Ie(t,e){for(var n=t.length;n--&&be(e,t[n],0)>-1;);return n}function De(t,e){for(var n=t.length,r=0;n--;)t[n]===e&&++r;return r}var $e=Ce({"À":"A","Á":"A","Â":"A","Ã":"A","Ä":"A","Å":"A","à":"a","á":"a","â":"a","ã":"a","ä":"a","å":"a","Ç":"C","ç":"c","Ð":"D","ð":"d","È":"E","É":"E","Ê":"E","Ë":"E","è":"e","é":"e","ê":"e","ë":"e","Ì":"I","Í":"I","Î":"I","Ï":"I","ì":"i","í":"i","î":"i","ï":"i","Ñ":"N","ñ":"n","Ò":"O","Ó":"O","Ô":"O","Õ":"O","Ö":"O","Ø":"O","ò":"o","ó":"o","ô":"o","õ":"o","ö":"o","ø":"o","Ù":"U","Ú":"U","Û":"U","Ü":"U","ù":"u","ú":"u","û":"u","ü":"u","Ý":"Y","ý":"y","ÿ":"y","Æ":"Ae","æ":"ae","Þ":"Th","þ":"th","ß":"ss","Ā":"A","Ă":"A","Ą":"A","ā":"a","ă":"a","ą":"a","Ć":"C","Ĉ":"C","Ċ":"C","Č":"C","ć":"c","ĉ":"c","ċ":"c","č":"c","Ď":"D","Đ":"D","ď":"d","đ":"d","Ē":"E","Ĕ":"E","Ė":"E","Ę":"E","Ě":"E","ē":"e","ĕ":"e","ė":"e","ę":"e","ě":"e","Ĝ":"G","Ğ":"G","Ġ":"G","Ģ":"G","ĝ":"g","ğ":"g","ġ":"g","ģ":"g","Ĥ":"H","Ħ":"H","ĥ":"h","ħ":"h","Ĩ":"I","Ī":"I","Ĭ":"I","Į":"I","İ":"I","ĩ":"i","ī":"i","ĭ":"i","į":"i","ı":"i","Ĵ":"J","ĵ":"j","Ķ":"K","ķ":"k","ĸ":"k","Ĺ":"L","Ļ":"L","Ľ":"L","Ŀ":"L","Ł":"L","ĺ":"l","ļ":"l","ľ":"l","ŀ":"l","ł":"l","Ń":"N","Ņ":"N","Ň":"N","Ŋ":"N","ń":"n","ņ":"n","ň":"n","ŋ":"n","Ō":"O","Ŏ":"O","Ő":"O","ō":"o","ŏ":"o","ő":"o","Ŕ":"R","Ŗ":"R","Ř":"R","ŕ":"r","ŗ":"r","ř":"r","Ś":"S","Ŝ":"S","Ş":"S","Š":"S","ś":"s","ŝ":"s","ş":"s","š":"s","Ţ":"T","Ť":"T","Ŧ":"T","ţ":"t","ť":"t","ŧ":"t","Ũ":"U","Ū":"U","Ŭ":"U","Ů":"U","Ű":"U","Ų":"U","ũ":"u","ū":"u","ŭ":"u","ů":"u","ű":"u","ų":"u","Ŵ":"W","ŵ":"w","Ŷ":"Y","ŷ":"y","Ÿ":"Y","Ź":"Z","Ż":"Z","Ž":"Z","ź":"z","ż":"z","ž":"z","IJ":"IJ","ij":"ij","Œ":"Oe","œ":"oe","ʼn":"'n","ſ":"s"}),je=Ce({"&":"&","<":"<",">":">",'"':""","'":"'"});function Ye(t){return"\\"+zt[t]}function Xe(t){return Dt.test(t)}function Ne(t){var e=-1,n=Array(t.size);return t.forEach((function(t,r){n[++e]=[r,t]})),n}function ze(t,e){return function(n){return t(e(n))}}function Re(t,e){for(var n=-1,r=t.length,i=0,s=[];++n",""":'"',"'":"'"});var Ke=function t(e){var n,r=(e=null==e?Wt:Ke.defaults(Wt.Object(),e,Ke.pick(Wt,jt))).Array,G=e.Date,ht=e.Error,ft=e.Function,pt=e.Math,gt=e.Object,dt=e.RegExp,vt=e.String,mt=e.TypeError,yt=r.prototype,_t=ft.prototype,bt=gt.prototype,wt=e["__core-js_shared__"],kt=_t.toString,xt=bt.hasOwnProperty,Pt=0,Ct=(n=/[^.]+$/.exec(wt&&wt.keys&&wt.keys.IE_PROTO||""))?"Symbol(src)_1."+n:"",Tt=bt.toString,St=kt.call(gt),Lt=Wt._,At=dt("^"+kt.call(xt).replace(F,"\\$&").replace(/hasOwnProperty|(function).*?(?=\\\()| for .+?(?=\\\])/g,"$1.*?")+"$"),Bt=Kt?e.Buffer:void 0,Et=e.Symbol,Dt=e.Uint8Array,zt=Bt?Bt.allocUnsafe:void 0,Ut=ze(gt.getPrototypeOf,gt),Ft=gt.create,qt=bt.propertyIsEnumerable,Gt=yt.splice,Qt=Et?Et.isConcatSpreadable:void 0,Jt=Et?Et.iterator:void 0,me=Et?Et.toStringTag:void 0,Ce=function(){try{var t=to(gt,"defineProperty");return t({},"",{}),t}catch(t){}}(),Qe=e.clearTimeout!==Wt.clearTimeout&&e.clearTimeout,Je=G&&G.now!==Wt.Date.now&&G.now,Ze=e.setTimeout!==Wt.setTimeout&&e.setTimeout,Ve=pt.ceil,tn=pt.floor,en=gt.getOwnPropertySymbols,nn=Bt?Bt.isBuffer:void 0,rn=e.isFinite,on=yt.join,sn=ze(gt.keys,gt),an=pt.max,un=pt.min,ln=G.now,cn=e.parseInt,hn=pt.random,fn=yt.reverse,pn=to(e,"DataView"),gn=to(e,"Map"),dn=to(e,"Promise"),vn=to(e,"Set"),mn=to(e,"WeakMap"),yn=to(gt,"create"),_n=mn&&new mn,bn={},wn=Lo(pn),kn=Lo(gn),xn=Lo(dn),Pn=Lo(vn),Cn=Lo(mn),Tn=Et?Et.prototype:void 0,Sn=Tn?Tn.valueOf:void 0,Ln=Tn?Tn.toString:void 0;function An(t){if(Fs(t)&&!Is(t)&&!(t instanceof En)){if(t instanceof Mn)return t;if(xt.call(t,"__wrapped__"))return Ao(t)}return new Mn(t)}var Bn=function(){function t(){}return function(e){if(!Us(e))return{};if(Ft)return Ft(e);t.prototype=e;var n=new t;return t.prototype=void 0,n}}();function On(){}function Mn(t,e){this.__wrapped__=t,this.__actions__=[],this.__chain__=!!e,this.__index__=0,this.__values__=void 0}function En(t){this.__wrapped__=t,this.__actions__=[],this.__dir__=1,this.__filtered__=!1,this.__iteratees__=[],this.__takeCount__=4294967295,this.__views__=[]}function In(t){var e=-1,n=null==t?0:t.length;for(this.clear();++e=e?t:e)),t}function Jn(t,e,n,r,i,o){var s,u=1&e,h=2&e,w=4&e;if(n&&(s=i?n(t,r,i,o):n(t)),void 0!==s)return s;if(!Us(t))return t;var M=Is(t);if(M){if(s=function(t){var e=t.length,n=new t.constructor(e);e&&"string"==typeof t[0]&&xt.call(t,"index")&&(n.index=t.index,n.input=t.input);return n}(t),!u)return yi(t,s)}else{var E=ro(t),I=E==f||E==p;if(Ys(t))return fi(t,u);if(E==v||E==a||I&&!i){if(s=h||I?{}:oo(t),!u)return h?function(t,e){return _i(t,no(t),e)}(t,function(t,e){return t&&_i(e,ka(e),t)}(s,t)):function(t,e){return _i(t,eo(t),e)}(t,qn(s,t))}else{if(!Nt[E])return i?t:{};s=function(t,e,n){var r=t.constructor;switch(e){case k:return pi(t);case l:case c:return new r(+t);case x:return function(t,e){var n=e?pi(t.buffer):t.buffer;return new t.constructor(n,t.byteOffset,t.byteLength)}(t,n);case P:case C:case T:case S:case L:case A:case"[object Uint8ClampedArray]":case B:case O:return gi(t,n);case g:return new r;case d:case _:return new r(t);case m:return function(t){var e=new t.constructor(t.source,nt.exec(t));return e.lastIndex=t.lastIndex,e}(t);case y:return new r;case b:return i=t,Sn?gt(Sn.call(i)):{}}var i}(t,E,u)}}o||(o=new Yn);var D=o.get(t);if(D)return D;o.set(t,s),Qs(t)?t.forEach((function(r){s.add(Jn(r,e,n,r,t,o))})):Ws(t)&&t.forEach((function(r,i){s.set(i,Jn(r,e,n,i,t,o))}));var $=M?void 0:(w?h?qi:Wi:h?ka:wa)(t);return se($||t,(function(r,i){$&&(r=t[i=r]),Un(s,i,Jn(r,e,n,i,t,o))})),s}function Zn(t,e,n){var r=n.length;if(null==t)return!r;for(t=gt(t);r--;){var i=n[r],o=e[i],s=t[i];if(void 0===s&&!(i in t)||!o(s))return!1}return!0}function Vn(t,e,n){if("function"!=typeof t)throw new mt(i);return wo((function(){t.apply(void 0,n)}),e)}function tr(t,e,n,r){var i=-1,o=ce,s=!0,a=t.length,u=[],l=e.length;if(!a)return u;n&&(e=fe(e,Be(n))),r?(o=he,s=!1):e.length>=200&&(o=Me,s=!1,e=new jn(e));t:for(;++i-1},Dn.prototype.set=function(t,e){var n=this.__data__,r=Fn(n,t);return r<0?(++this.size,n.push([t,e])):n[r][1]=e,this},$n.prototype.clear=function(){this.size=0,this.__data__={hash:new In,map:new(gn||Dn),string:new In}},$n.prototype.delete=function(t){var e=Zi(this,t).delete(t);return this.size-=e?1:0,e},$n.prototype.get=function(t){return Zi(this,t).get(t)},$n.prototype.has=function(t){return Zi(this,t).has(t)},$n.prototype.set=function(t,e){var n=Zi(this,t),r=n.size;return n.set(t,e),this.size+=n.size==r?0:1,this},jn.prototype.add=jn.prototype.push=function(t){return this.__data__.set(t,"__lodash_hash_undefined__"),this},jn.prototype.has=function(t){return this.__data__.has(t)},Yn.prototype.clear=function(){this.__data__=new Dn,this.size=0},Yn.prototype.delete=function(t){var e=this.__data__,n=e.delete(t);return this.size=e.size,n},Yn.prototype.get=function(t){return this.__data__.get(t)},Yn.prototype.has=function(t){return this.__data__.has(t)},Yn.prototype.set=function(t,e){var n=this.__data__;if(n instanceof Dn){var r=n.__data__;if(!gn||r.length<199)return r.push([t,e]),this.size=++n.size,this;n=this.__data__=new $n(r)}return n.set(t,e),this.size=n.size,this};var er=ki(lr),nr=ki(cr,!0);function rr(t,e){var n=!0;return er(t,(function(t,r,i){return n=!!e(t,r,i)})),n}function ir(t,e,n){for(var r=-1,i=t.length;++r0&&n(a)?e>1?sr(a,e-1,n,r,i):pe(i,a):r||(i[i.length]=a)}return i}var ar=xi(),ur=xi(!0);function lr(t,e){return t&&ar(t,e,wa)}function cr(t,e){return t&&ur(t,e,wa)}function hr(t,e){return le(e,(function(e){return zs(t[e])}))}function fr(t,e){for(var n=0,r=(e=ui(e,t)).length;null!=t&&ne}function vr(t,e){return null!=t&&xt.call(t,e)}function mr(t,e){return null!=t&&e in gt(t)}function yr(t,e,n){for(var i=n?he:ce,o=t[0].length,s=t.length,a=s,u=r(s),l=1/0,c=[];a--;){var h=t[a];a&&e&&(h=fe(h,Be(e))),l=un(h.length,l),u[a]=!n&&(e||o>=120&&h.length>=120)?new jn(a&&h):void 0}h=t[0];var f=-1,p=u[0];t:for(;++f=a)return u;var l=n[r];return u*("desc"==l?-1:1)}}return t.index-e.index}(t,e,n)}))}function Ir(t,e,n){for(var r=-1,i=e.length,o={};++r-1;)a!==t&&Gt.call(a,u,1),Gt.call(t,u,1);return t}function $r(t,e){for(var n=t?e.length:0,r=n-1;n--;){var i=e[n];if(n==r||i!==o){var o=i;ao(i)?Gt.call(t,i,1):ti(t,i)}}return t}function jr(t,e){return t+tn(hn()*(e-t+1))}function Yr(t,e){var n="";if(!t||e<1||e>9007199254740991)return n;do{e%2&&(n+=t),(e=tn(e/2))&&(t+=t)}while(e);return n}function Xr(t,e){return ko(vo(t,e,qa),t+"")}function Nr(t){return Nn(Ba(t))}function zr(t,e){var n=Ba(t);return Co(n,Qn(e,0,n.length))}function Rr(t,e,n,r){if(!Us(t))return t;for(var i=-1,o=(e=ui(e,t)).length,s=o-1,a=t;null!=a&&++io?0:o+e),(n=n>o?o:n)<0&&(n+=o),o=e>n?0:n-e>>>0,e>>>=0;for(var s=r(o);++i>>1,s=t[o];null!==s&&!Zs(s)&&(n?s<=e:s=200){var l=e?null:Yi(t);if(l)return He(l);s=!1,i=Me,u=new jn}else u=e?[]:a;t:for(;++r=r?t:Wr(t,e,n)}var hi=Qe||function(t){return Wt.clearTimeout(t)};function fi(t,e){if(e)return t.slice();var n=t.length,r=zt?zt(n):new t.constructor(n);return t.copy(r),r}function pi(t){var e=new t.constructor(t.byteLength);return new Dt(e).set(new Dt(t)),e}function gi(t,e){var n=e?pi(t.buffer):t.buffer;return new t.constructor(n,t.byteOffset,t.length)}function di(t,e){if(t!==e){var n=void 0!==t,r=null===t,i=t==t,o=Zs(t),s=void 0!==e,a=null===e,u=e==e,l=Zs(e);if(!a&&!l&&!o&&t>e||o&&s&&u&&!a&&!l||r&&s&&u||!n&&u||!i)return 1;if(!r&&!o&&!l&&t1?n[i-1]:void 0,s=i>2?n[2]:void 0;for(o=t.length>3&&"function"==typeof o?(i--,o):void 0,s&&uo(n[0],n[1],s)&&(o=i<3?void 0:o,i=1),e=gt(e);++r-1?i[o?e[s]:s]:void 0}}function Li(t){return Fi((function(e){var n=e.length,r=n,o=Mn.prototype.thru;for(t&&e.reverse();r--;){var s=e[r];if("function"!=typeof s)throw new mt(i);if(o&&!a&&"wrapper"==Ki(s))var a=new Mn([],!0)}for(r=a?r:n;++r1&&_.reverse(),h&&la))return!1;var l=o.get(t),c=o.get(e);if(l&&c)return l==e&&c==t;var h=-1,f=!0,p=2&n?new jn:void 0;for(o.set(t,e),o.set(e,t);++h-1&&t%1==0&&t1?"& ":"")+e[r],e=e.join(n>2?", ":" "),t.replace(K,"{\n/* [wrapped with "+e+"] */\n")}(r,function(t,e){return se(s,(function(n){var r="_."+n[0];e&n[1]&&!ce(t,r)&&t.push(r)})),t.sort()}(function(t){var e=t.match(Q);return e?e[1].split(J):[]}(r),n)))}function Po(t){var e=0,n=0;return function(){var r=ln(),i=16-(r-n);if(n=r,i>0){if(++e>=800)return arguments[0]}else e=0;return t.apply(void 0,arguments)}}function Co(t,e){var n=-1,r=t.length,i=r-1;for(e=void 0===e?r:e;++n1?t[e-1]:void 0;return n="function"==typeof n?(t.pop(),n):void 0,Ko(t,n)}));function ns(t){var e=An(t);return e.__chain__=!0,e}function rs(t,e){return e(t)}var is=Fi((function(t){var e=t.length,n=e?t[0]:0,r=this.__wrapped__,i=function(e){return Kn(e,t)};return!(e>1||this.__actions__.length)&&r instanceof En&&ao(n)?((r=r.slice(n,+n+(e?1:0))).__actions__.push({func:rs,args:[i],thisArg:void 0}),new Mn(r,this.__chain__).thru((function(t){return e&&!t.length&&t.push(void 0),t}))):this.thru(i)}));var os=bi((function(t,e,n){xt.call(t,n)?++t[n]:Gn(t,n,1)}));var ss=Si(Eo),as=Si(Io);function us(t,e){return(Is(t)?se:er)(t,Ji(e,3))}function ls(t,e){return(Is(t)?ae:nr)(t,Ji(e,3))}var cs=bi((function(t,e,n){xt.call(t,n)?t[n].push(e):Gn(t,n,[e])}));var hs=Xr((function(t,e,n){var i=-1,o="function"==typeof e,s=$s(t)?r(t.length):[];return er(t,(function(t){s[++i]=o?ie(e,t,n):_r(t,e,n)})),s})),fs=bi((function(t,e,n){Gn(t,n,e)}));function ps(t,e){return(Is(t)?fe:Lr)(t,Ji(e,3))}var gs=bi((function(t,e,n){t[n?0:1].push(e)}),(function(){return[[],[]]}));var ds=Xr((function(t,e){if(null==t)return[];var n=e.length;return n>1&&uo(t,e[0],e[1])?e=[]:n>2&&uo(e[0],e[1],e[2])&&(e=[e[0]]),Er(t,sr(e,1),[])})),vs=Je||function(){return Wt.Date.now()};function ms(t,e,n){return e=n?void 0:e,Ni(t,128,void 0,void 0,void 0,void 0,e=t&&null==e?t.length:e)}function ys(t,e){var n;if("function"!=typeof e)throw new mt(i);return t=ia(t),function(){return--t>0&&(n=e.apply(this,arguments)),t<=1&&(e=void 0),n}}var _s=Xr((function(t,e,n){var r=1;if(n.length){var i=Re(n,Qi(_s));r|=32}return Ni(t,r,e,n,i)})),bs=Xr((function(t,e,n){var r=3;if(n.length){var i=Re(n,Qi(bs));r|=32}return Ni(e,r,t,n,i)}));function ws(t,e,n){var r,o,s,a,u,l,c=0,h=!1,f=!1,p=!0;if("function"!=typeof t)throw new mt(i);function g(e){var n=r,i=o;return r=o=void 0,c=e,a=t.apply(i,n)}function d(t){return c=t,u=wo(m,e),h?g(t):a}function v(t){var n=t-l;return void 0===l||n>=e||n<0||f&&t-c>=s}function m(){var t=vs();if(v(t))return y(t);u=wo(m,function(t){var n=e-(t-l);return f?un(n,s-(t-c)):n}(t))}function y(t){return u=void 0,p&&r?g(t):(r=o=void 0,a)}function _(){var t=vs(),n=v(t);if(r=arguments,o=this,l=t,n){if(void 0===u)return d(l);if(f)return hi(u),u=wo(m,e),g(l)}return void 0===u&&(u=wo(m,e)),a}return e=sa(e)||0,Us(n)&&(h=!!n.leading,s=(f="maxWait"in n)?an(sa(n.maxWait)||0,e):s,p="trailing"in n?!!n.trailing:p),_.cancel=function(){void 0!==u&&hi(u),c=0,r=l=o=u=void 0},_.flush=function(){return void 0===u?a:y(vs())},_}var ks=Xr((function(t,e){return Vn(t,1,e)})),xs=Xr((function(t,e,n){return Vn(t,sa(e)||0,n)}));function Ps(t,e){if("function"!=typeof t||null!=e&&"function"!=typeof e)throw new mt(i);var n=function(){var r=arguments,i=e?e.apply(this,r):r[0],o=n.cache;if(o.has(i))return o.get(i);var s=t.apply(this,r);return n.cache=o.set(i,s)||o,s};return n.cache=new(Ps.Cache||$n),n}function Cs(t){if("function"!=typeof t)throw new mt(i);return function(){var e=arguments;switch(e.length){case 0:return!t.call(this);case 1:return!t.call(this,e[0]);case 2:return!t.call(this,e[0],e[1]);case 3:return!t.call(this,e[0],e[1],e[2])}return!t.apply(this,e)}}Ps.Cache=$n;var Ts=li((function(t,e){var n=(e=1==e.length&&Is(e[0])?fe(e[0],Be(Ji())):fe(sr(e,1),Be(Ji()))).length;return Xr((function(r){for(var i=-1,o=un(r.length,n);++i=e})),Es=br(function(){return arguments}())?br:function(t){return Fs(t)&&xt.call(t,"callee")&&!qt.call(t,"callee")},Is=r.isArray,Ds=Zt?Be(Zt):function(t){return Fs(t)&&gr(t)==k};function $s(t){return null!=t&&Hs(t.length)&&!zs(t)}function js(t){return Fs(t)&&$s(t)}var Ys=nn||su,Xs=Vt?Be(Vt):function(t){return Fs(t)&&gr(t)==c};function Ns(t){if(!Fs(t))return!1;var e=gr(t);return e==h||"[object DOMException]"==e||"string"==typeof t.message&&"string"==typeof t.name&&!Gs(t)}function zs(t){if(!Us(t))return!1;var e=gr(t);return e==f||e==p||"[object AsyncFunction]"==e||"[object Proxy]"==e}function Rs(t){return"number"==typeof t&&t==ia(t)}function Hs(t){return"number"==typeof t&&t>-1&&t%1==0&&t<=9007199254740991}function Us(t){var e=typeof t;return null!=t&&("object"==e||"function"==e)}function Fs(t){return null!=t&&"object"==typeof t}var Ws=te?Be(te):function(t){return Fs(t)&&ro(t)==g};function qs(t){return"number"==typeof t||Fs(t)&&gr(t)==d}function Gs(t){if(!Fs(t)||gr(t)!=v)return!1;var e=Ut(t);if(null===e)return!0;var n=xt.call(e,"constructor")&&e.constructor;return"function"==typeof n&&n instanceof n&&kt.call(n)==St}var Ks=ee?Be(ee):function(t){return Fs(t)&&gr(t)==m};var Qs=ne?Be(ne):function(t){return Fs(t)&&ro(t)==y};function Js(t){return"string"==typeof t||!Is(t)&&Fs(t)&&gr(t)==_}function Zs(t){return"symbol"==typeof t||Fs(t)&&gr(t)==b}var Vs=re?Be(re):function(t){return Fs(t)&&Hs(t.length)&&!!Xt[gr(t)]};var ta=Di(Sr),ea=Di((function(t,e){return t<=e}));function na(t){if(!t)return[];if($s(t))return Js(t)?We(t):yi(t);if(Jt&&t[Jt])return function(t){for(var e,n=[];!(e=t.next()).done;)n.push(e.value);return n}(t[Jt]());var e=ro(t);return(e==g?Ne:e==y?He:Ba)(t)}function ra(t){return t?(t=sa(t))===1/0||t===-1/0?17976931348623157e292*(t<0?-1:1):t==t?t:0:0===t?t:0}function ia(t){var e=ra(t),n=e%1;return e==e?n?e-n:e:0}function oa(t){return t?Qn(ia(t),0,4294967295):0}function sa(t){if("number"==typeof t)return t;if(Zs(t))return NaN;if(Us(t)){var e="function"==typeof t.valueOf?t.valueOf():t;t=Us(e)?e+"":e}if("string"!=typeof t)return 0===t?t:+t;t=Ae(t);var n=it.test(t);return n||st.test(t)?Ht(t.slice(2),n?2:8):rt.test(t)?NaN:+t}function aa(t){return _i(t,ka(t))}function ua(t){return null==t?"":Zr(t)}var la=wi((function(t,e){if(fo(e)||$s(e))_i(e,wa(e),t);else for(var n in e)xt.call(e,n)&&Un(t,n,e[n])})),ca=wi((function(t,e){_i(e,ka(e),t)})),ha=wi((function(t,e,n,r){_i(e,ka(e),t,r)})),fa=wi((function(t,e,n,r){_i(e,wa(e),t,r)})),pa=Fi(Kn);var ga=Xr((function(t,e){t=gt(t);var n=-1,r=e.length,i=r>2?e[2]:void 0;for(i&&uo(e[0],e[1],i)&&(r=1);++n1),e})),_i(t,qi(t),n),r&&(n=Jn(n,7,Hi));for(var i=e.length;i--;)ti(n,e[i]);return n}));var Ta=Fi((function(t,e){return null==t?{}:function(t,e){return Ir(t,e,(function(e,n){return ma(t,n)}))}(t,e)}));function Sa(t,e){if(null==t)return{};var n=fe(qi(t),(function(t){return[t]}));return e=Ji(e),Ir(t,n,(function(t,n){return e(t,n[0])}))}var La=Xi(wa),Aa=Xi(ka);function Ba(t){return null==t?[]:Oe(t,wa(t))}var Oa=Ci((function(t,e,n){return e=e.toLowerCase(),t+(n?Ma(e):e)}));function Ma(t){return Na(ua(t).toLowerCase())}function Ea(t){return(t=ua(t))&&t.replace(ut,$e).replace(Mt,"")}var Ia=Ci((function(t,e,n){return t+(n?"-":"")+e.toLowerCase()})),Da=Ci((function(t,e,n){return t+(n?" ":"")+e.toLowerCase()})),$a=Pi("toLowerCase");var ja=Ci((function(t,e,n){return t+(n?"_":"")+e.toLowerCase()}));var Ya=Ci((function(t,e,n){return t+(n?" ":"")+Na(e)}));var Xa=Ci((function(t,e,n){return t+(n?" ":"")+e.toUpperCase()})),Na=Pi("toUpperCase");function za(t,e,n){return t=ua(t),void 0===(e=n?void 0:e)?function(t){return $t.test(t)}(t)?function(t){return t.match(It)||[]}(t):function(t){return t.match(Z)||[]}(t):t.match(e)||[]}var Ra=Xr((function(t,e){try{return ie(t,void 0,e)}catch(t){return Ns(t)?t:new ht(t)}})),Ha=Fi((function(t,e){return se(e,(function(e){e=So(e),Gn(t,e,_s(t[e],t))})),t}));function Ua(t){return function(){return t}}var Fa=Li(),Wa=Li(!0);function qa(t){return t}function Ga(t){return Pr("function"==typeof t?t:Jn(t,1))}var Ka=Xr((function(t,e){return function(n){return _r(n,t,e)}})),Qa=Xr((function(t,e){return function(n){return _r(t,n,e)}}));function Ja(t,e,n){var r=wa(e),i=hr(e,r);null!=n||Us(e)&&(i.length||!r.length)||(n=e,e=t,t=this,i=hr(e,wa(e)));var o=!(Us(n)&&"chain"in n&&!n.chain),s=zs(t);return se(i,(function(n){var r=e[n];t[n]=r,s&&(t.prototype[n]=function(){var e=this.__chain__;if(o||e){var n=t(this.__wrapped__),i=n.__actions__=yi(this.__actions__);return i.push({func:r,args:arguments,thisArg:t}),n.__chain__=e,n}return r.apply(t,pe([this.value()],arguments))})})),t}function Za(){}var Va=Mi(fe),tu=Mi(ue),eu=Mi(ve);function nu(t){return lo(t)?Pe(So(t)):function(t){return function(e){return fr(e,t)}}(t)}var ru=Ii(),iu=Ii(!0);function ou(){return[]}function su(){return!1}var au=Oi((function(t,e){return t+e}),0),uu=ji("ceil"),lu=Oi((function(t,e){return t/e}),1),cu=ji("floor");var hu,fu=Oi((function(t,e){return t*e}),1),pu=ji("round"),gu=Oi((function(t,e){return t-e}),0);return An.after=function(t,e){if("function"!=typeof e)throw new mt(i);return t=ia(t),function(){if(--t<1)return e.apply(this,arguments)}},An.ary=ms,An.assign=la,An.assignIn=ca,An.assignInWith=ha,An.assignWith=fa,An.at=pa,An.before=ys,An.bind=_s,An.bindAll=Ha,An.bindKey=bs,An.castArray=function(){if(!arguments.length)return[];var t=arguments[0];return Is(t)?t:[t]},An.chain=ns,An.chunk=function(t,e,n){e=(n?uo(t,e,n):void 0===e)?1:an(ia(e),0);var i=null==t?0:t.length;if(!i||e<1)return[];for(var o=0,s=0,a=r(Ve(i/e));oi?0:i+n),(r=void 0===r||r>i?i:ia(r))<0&&(r+=i),r=n>r?0:oa(r);n>>0)?(t=ua(t))&&("string"==typeof e||null!=e&&!Ks(e))&&!(e=Zr(e))&&Xe(t)?ci(We(t),0,n):t.split(e,n):[]},An.spread=function(t,e){if("function"!=typeof t)throw new mt(i);return e=null==e?0:an(ia(e),0),Xr((function(n){var r=n[e],i=ci(n,0,e);return r&&pe(i,r),ie(t,this,i)}))},An.tail=function(t){var e=null==t?0:t.length;return e?Wr(t,1,e):[]},An.take=function(t,e,n){return t&&t.length?Wr(t,0,(e=n||void 0===e?1:ia(e))<0?0:e):[]},An.takeRight=function(t,e,n){var r=null==t?0:t.length;return r?Wr(t,(e=r-(e=n||void 0===e?1:ia(e)))<0?0:e,r):[]},An.takeRightWhile=function(t,e){return t&&t.length?ni(t,Ji(e,3),!1,!0):[]},An.takeWhile=function(t,e){return t&&t.length?ni(t,Ji(e,3)):[]},An.tap=function(t,e){return e(t),t},An.throttle=function(t,e,n){var r=!0,o=!0;if("function"!=typeof t)throw new mt(i);return Us(n)&&(r="leading"in n?!!n.leading:r,o="trailing"in n?!!n.trailing:o),ws(t,e,{leading:r,maxWait:e,trailing:o})},An.thru=rs,An.toArray=na,An.toPairs=La,An.toPairsIn=Aa,An.toPath=function(t){return Is(t)?fe(t,So):Zs(t)?[t]:yi(To(ua(t)))},An.toPlainObject=aa,An.transform=function(t,e,n){var r=Is(t),i=r||Ys(t)||Vs(t);if(e=Ji(e,4),null==n){var o=t&&t.constructor;n=i?r?new o:[]:Us(t)&&zs(o)?Bn(Ut(t)):{}}return(i?se:lr)(t,(function(t,r,i){return e(n,t,r,i)})),n},An.unary=function(t){return ms(t,1)},An.union=Fo,An.unionBy=Wo,An.unionWith=qo,An.uniq=function(t){return t&&t.length?Vr(t):[]},An.uniqBy=function(t,e){return t&&t.length?Vr(t,Ji(e,2)):[]},An.uniqWith=function(t,e){return e="function"==typeof e?e:void 0,t&&t.length?Vr(t,void 0,e):[]},An.unset=function(t,e){return null==t||ti(t,e)},An.unzip=Go,An.unzipWith=Ko,An.update=function(t,e,n){return null==t?t:ei(t,e,ai(n))},An.updateWith=function(t,e,n,r){return r="function"==typeof r?r:void 0,null==t?t:ei(t,e,ai(n),r)},An.values=Ba,An.valuesIn=function(t){return null==t?[]:Oe(t,ka(t))},An.without=Qo,An.words=za,An.wrap=function(t,e){return Ss(ai(e),t)},An.xor=Jo,An.xorBy=Zo,An.xorWith=Vo,An.zip=ts,An.zipObject=function(t,e){return oi(t||[],e||[],Un)},An.zipObjectDeep=function(t,e){return oi(t||[],e||[],Rr)},An.zipWith=es,An.entries=La,An.entriesIn=Aa,An.extend=ca,An.extendWith=ha,Ja(An,An),An.add=au,An.attempt=Ra,An.camelCase=Oa,An.capitalize=Ma,An.ceil=uu,An.clamp=function(t,e,n){return void 0===n&&(n=e,e=void 0),void 0!==n&&(n=(n=sa(n))==n?n:0),void 0!==e&&(e=(e=sa(e))==e?e:0),Qn(sa(t),e,n)},An.clone=function(t){return Jn(t,4)},An.cloneDeep=function(t){return Jn(t,5)},An.cloneDeepWith=function(t,e){return Jn(t,5,e="function"==typeof e?e:void 0)},An.cloneWith=function(t,e){return Jn(t,4,e="function"==typeof e?e:void 0)},An.conformsTo=function(t,e){return null==e||Zn(t,e,wa(e))},An.deburr=Ea,An.defaultTo=function(t,e){return null==t||t!=t?e:t},An.divide=lu,An.endsWith=function(t,e,n){t=ua(t),e=Zr(e);var r=t.length,i=n=void 0===n?r:Qn(ia(n),0,r);return(n-=e.length)>=0&&t.slice(n,i)==e},An.eq=Bs,An.escape=function(t){return(t=ua(t))&&Y.test(t)?t.replace($,je):t},An.escapeRegExp=function(t){return(t=ua(t))&&W.test(t)?t.replace(F,"\\$&"):t},An.every=function(t,e,n){var r=Is(t)?ue:rr;return n&&uo(t,e,n)&&(e=void 0),r(t,Ji(e,3))},An.find=ss,An.findIndex=Eo,An.findKey=function(t,e){return ye(t,Ji(e,3),lr)},An.findLast=as,An.findLastIndex=Io,An.findLastKey=function(t,e){return ye(t,Ji(e,3),cr)},An.floor=cu,An.forEach=us,An.forEachRight=ls,An.forIn=function(t,e){return null==t?t:ar(t,Ji(e,3),ka)},An.forInRight=function(t,e){return null==t?t:ur(t,Ji(e,3),ka)},An.forOwn=function(t,e){return t&&lr(t,Ji(e,3))},An.forOwnRight=function(t,e){return t&&cr(t,Ji(e,3))},An.get=va,An.gt=Os,An.gte=Ms,An.has=function(t,e){return null!=t&&io(t,e,vr)},An.hasIn=ma,An.head=$o,An.identity=qa,An.includes=function(t,e,n,r){t=$s(t)?t:Ba(t),n=n&&!r?ia(n):0;var i=t.length;return n<0&&(n=an(i+n,0)),Js(t)?n<=i&&t.indexOf(e,n)>-1:!!i&&be(t,e,n)>-1},An.indexOf=function(t,e,n){var r=null==t?0:t.length;if(!r)return-1;var i=null==n?0:ia(n);return i<0&&(i=an(r+i,0)),be(t,e,i)},An.inRange=function(t,e,n){return e=ra(e),void 0===n?(n=e,e=0):n=ra(n),function(t,e,n){return t>=un(e,n)&&t=-9007199254740991&&t<=9007199254740991},An.isSet=Qs,An.isString=Js,An.isSymbol=Zs,An.isTypedArray=Vs,An.isUndefined=function(t){return void 0===t},An.isWeakMap=function(t){return Fs(t)&&ro(t)==w},An.isWeakSet=function(t){return Fs(t)&&"[object WeakSet]"==gr(t)},An.join=function(t,e){return null==t?"":on.call(t,e)},An.kebabCase=Ia,An.last=No,An.lastIndexOf=function(t,e,n){var r=null==t?0:t.length;if(!r)return-1;var i=r;return void 0!==n&&(i=(i=ia(n))<0?an(r+i,0):un(i,r-1)),e==e?function(t,e,n){for(var r=n+1;r--;)if(t[r]===e)return r;return r}(t,e,i):_e(t,ke,i,!0)},An.lowerCase=Da,An.lowerFirst=$a,An.lt=ta,An.lte=ea,An.max=function(t){return t&&t.length?ir(t,qa,dr):void 0},An.maxBy=function(t,e){return t&&t.length?ir(t,Ji(e,2),dr):void 0},An.mean=function(t){return xe(t,qa)},An.meanBy=function(t,e){return xe(t,Ji(e,2))},An.min=function(t){return t&&t.length?ir(t,qa,Sr):void 0},An.minBy=function(t,e){return t&&t.length?ir(t,Ji(e,2),Sr):void 0},An.stubArray=ou,An.stubFalse=su,An.stubObject=function(){return{}},An.stubString=function(){return""},An.stubTrue=function(){return!0},An.multiply=fu,An.nth=function(t,e){return t&&t.length?Mr(t,ia(e)):void 0},An.noConflict=function(){return Wt._===this&&(Wt._=Lt),this},An.noop=Za,An.now=vs,An.pad=function(t,e,n){t=ua(t);var r=(e=ia(e))?Fe(t):0;if(!e||r>=e)return t;var i=(e-r)/2;return Ei(tn(i),n)+t+Ei(Ve(i),n)},An.padEnd=function(t,e,n){t=ua(t);var r=(e=ia(e))?Fe(t):0;return e&&re){var r=t;t=e,e=r}if(n||t%1||e%1){var i=hn();return un(t+i*(e-t+Rt("1e-"+((i+"").length-1))),e)}return jr(t,e)},An.reduce=function(t,e,n){var r=Is(t)?ge:Te,i=arguments.length<3;return r(t,Ji(e,4),n,i,er)},An.reduceRight=function(t,e,n){var r=Is(t)?de:Te,i=arguments.length<3;return r(t,Ji(e,4),n,i,nr)},An.repeat=function(t,e,n){return e=(n?uo(t,e,n):void 0===e)?1:ia(e),Yr(ua(t),e)},An.replace=function(){var t=arguments,e=ua(t[0]);return t.length<3?e:e.replace(t[1],t[2])},An.result=function(t,e,n){var r=-1,i=(e=ui(e,t)).length;for(i||(i=1,t=void 0);++r9007199254740991)return[];var n=4294967295,r=un(t,4294967295);t-=4294967295;for(var i=Le(r,e=Ji(e));++n=o)return t;var a=n-Fe(r);if(a<1)return r;var u=s?ci(s,0,a).join(""):t.slice(0,a);if(void 0===i)return u+r;if(s&&(a+=u.length-a),Ks(i)){if(t.slice(a).search(i)){var l,c=u;for(i.global||(i=dt(i.source,ua(nt.exec(i))+"g")),i.lastIndex=0;l=i.exec(c);)var h=l.index;u=u.slice(0,void 0===h?a:h)}}else if(t.indexOf(Zr(i),a)!=a){var f=u.lastIndexOf(i);f>-1&&(u=u.slice(0,f))}return u+r},An.unescape=function(t){return(t=ua(t))&&j.test(t)?t.replace(D,Ge):t},An.uniqueId=function(t){var e=++Pt;return ua(t)+e},An.upperCase=Xa,An.upperFirst=Na,An.each=us,An.eachRight=ls,An.first=$o,Ja(An,(hu={},lr(An,(function(t,e){xt.call(An.prototype,e)||(hu[e]=t)})),hu),{chain:!1}),An.VERSION="4.17.21",se(["bind","bindKey","curry","curryRight","partial","partialRight"],(function(t){An[t].placeholder=An})),se(["drop","take"],(function(t,e){En.prototype[t]=function(n){n=void 0===n?1:an(ia(n),0);var r=this.__filtered__&&!e?new En(this):this.clone();return r.__filtered__?r.__takeCount__=un(n,r.__takeCount__):r.__views__.push({size:un(n,4294967295),type:t+(r.__dir__<0?"Right":"")}),r},En.prototype[t+"Right"]=function(e){return this.reverse()[t](e).reverse()}})),se(["filter","map","takeWhile"],(function(t,e){var n=e+1,r=1==n||3==n;En.prototype[t]=function(t){var e=this.clone();return e.__iteratees__.push({iteratee:Ji(t,3),type:n}),e.__filtered__=e.__filtered__||r,e}})),se(["head","last"],(function(t,e){var n="take"+(e?"Right":"");En.prototype[t]=function(){return this[n](1).value()[0]}})),se(["initial","tail"],(function(t,e){var n="drop"+(e?"":"Right");En.prototype[t]=function(){return this.__filtered__?new En(this):this[n](1)}})),En.prototype.compact=function(){return this.filter(qa)},En.prototype.find=function(t){return this.filter(t).head()},En.prototype.findLast=function(t){return this.reverse().find(t)},En.prototype.invokeMap=Xr((function(t,e){return"function"==typeof t?new En(this):this.map((function(n){return _r(n,t,e)}))})),En.prototype.reject=function(t){return this.filter(Cs(Ji(t)))},En.prototype.slice=function(t,e){t=ia(t);var n=this;return n.__filtered__&&(t>0||e<0)?new En(n):(t<0?n=n.takeRight(-t):t&&(n=n.drop(t)),void 0!==e&&(n=(e=ia(e))<0?n.dropRight(-e):n.take(e-t)),n)},En.prototype.takeRightWhile=function(t){return this.reverse().takeWhile(t).reverse()},En.prototype.toArray=function(){return this.take(4294967295)},lr(En.prototype,(function(t,e){var n=/^(?:filter|find|map|reject)|While$/.test(e),r=/^(?:head|last)$/.test(e),i=An[r?"take"+("last"==e?"Right":""):e],o=r||/^find/.test(e);i&&(An.prototype[e]=function(){var e=this.__wrapped__,s=r?[1]:arguments,a=e instanceof En,u=s[0],l=a||Is(e),c=function(t){var e=i.apply(An,pe([t],s));return r&&h?e[0]:e};l&&n&&"function"==typeof u&&1!=u.length&&(a=l=!1);var h=this.__chain__,f=!!this.__actions__.length,p=o&&!h,g=a&&!f;if(!o&&l){e=g?e:new En(this);var d=t.apply(e,s);return d.__actions__.push({func:rs,args:[c],thisArg:void 0}),new Mn(d,h)}return p&&g?t.apply(this,s):(d=this.thru(c),p?r?d.value()[0]:d.value():d)})})),se(["pop","push","shift","sort","splice","unshift"],(function(t){var e=yt[t],n=/^(?:push|sort|unshift)$/.test(t)?"tap":"thru",r=/^(?:pop|shift)$/.test(t);An.prototype[t]=function(){var t=arguments;if(r&&!this.__chain__){var i=this.value();return e.apply(Is(i)?i:[],t)}return this[n]((function(n){return e.apply(Is(n)?n:[],t)}))}})),lr(En.prototype,(function(t,e){var n=An[e];if(n){var r=n.name+"";xt.call(bn,r)||(bn[r]=[]),bn[r].push({name:e,func:n})}})),bn[Ai(void 0,2).name]=[{name:"wrapper",func:void 0}],En.prototype.clone=function(){var t=new En(this.__wrapped__);return t.__actions__=yi(this.__actions__),t.__dir__=this.__dir__,t.__filtered__=this.__filtered__,t.__iteratees__=yi(this.__iteratees__),t.__takeCount__=this.__takeCount__,t.__views__=yi(this.__views__),t},En.prototype.reverse=function(){if(this.__filtered__){var t=new En(this);t.__dir__=-1,t.__filtered__=!0}else(t=this.clone()).__dir__*=-1;return t},En.prototype.value=function(){var t=this.__wrapped__.value(),e=this.__dir__,n=Is(t),r=e<0,i=n?t.length:0,o=function(t,e,n){var r=-1,i=n.length;for(;++r=this.__values__.length;return{done:t,value:t?void 0:this.__values__[this.__index__++]}},An.prototype.plant=function(t){for(var e,n=this;n instanceof On;){var r=Ao(n);r.__index__=0,r.__values__=void 0,e?i.__wrapped__=r:e=r;var i=r;n=n.__wrapped__}return i.__wrapped__=t,e},An.prototype.reverse=function(){var t=this.__wrapped__;if(t instanceof En){var e=t;return this.__actions__.length&&(e=new En(this)),(e=e.reverse()).__actions__.push({func:rs,args:[Uo],thisArg:void 0}),new Mn(e,this.__chain__)}return this.thru(Uo)},An.prototype.toJSON=An.prototype.valueOf=An.prototype.value=function(){return ri(this.__wrapped__,this.__actions__)},An.prototype.first=An.prototype.head,Jt&&(An.prototype[Jt]=function(){return this}),An}();Wt._=Ke,void 0===(r=function(){return Ke}.call(e,n,e,t))||(t.exports=r)}).call(this)}).call(this,n(50)(t))},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e){t.exports=function(t){return null==t}},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},function(t,e,n){},,function(t,e,n){"use strict";n.r(e);var r=n(11),i={name:"SidebarGroup",props:["item","open","collapsable","depth"],components:{DropdownTransition:n(291).a},beforeCreate(){this.$options.components.SidebarLinks=n(290).default},methods:{isActive:r.f}},o=(n(329),n(4)),s=Object(o.a)(i,(function(){var t=this,e=t._self._c;return e("section",{staticClass:"sidebar-group",class:[{collapsable:t.collapsable,"is-sub-group":0!==t.depth},"depth-"+t.depth]},[t.item.path?e("router-link",{staticClass:"sidebar-heading clickable",class:{open:t.open,active:t.isActive(t.$route,t.item.path)},attrs:{to:t.item.path},nativeOn:{click:function(e){return t.$emit("toggle")}}},[e("span",[t._v(t._s(t.item.title))]),t._v(" "),t.collapsable?e("span",{staticClass:"arrow",class:t.open?"down":"right"}):t._e()]):e("p",{staticClass:"sidebar-heading",class:{open:t.open},on:{click:function(e){return t.$emit("toggle")}}},[e("span",[t._v(t._s(t.item.title))]),t._v(" "),t.collapsable?e("span",{staticClass:"arrow",class:t.open?"down":"right"}):t._e()]),t._v(" "),e("DropdownTransition",[t.open||!t.collapsable?e("SidebarLinks",{staticClass:"sidebar-group-items",attrs:{items:t.item.children,"sidebar-depth":t.item.sidebarDepth,"initial-open-group-index":t.item.initialOpenGroupIndex,depth:t.depth+1}}):t._e()],1)],1)}),[],!1,null,null,null).exports;function a(t,e,n,r){return t("router-link",{props:{to:e,activeClass:"",exactActiveClass:""},class:{active:r,"sidebar-link":!0}},n)}function u(t,e,n,i,o,s=1){return!e||s>o?null:t("ul",{class:"sidebar-sub-headers"},e.map(e=>{const l=Object(r.f)(i,n+"#"+e.slug);return t("li",{class:"sidebar-sub-header level"+e.level},[a(t,n+"#"+e.slug,e.title,l),u(t,e.children,n,i,o,s+1)])}))}var l={functional:!0,props:["item","sidebarDepth"],render(t,{parent:{$page:e,$site:n,$route:i,$themeConfig:o,$themeLocaleConfig:s},props:{item:l,sidebarDepth:c}}){const h=Object(r.f)(i,l.path),f="auto"===l.type?h||l.children.some(t=>Object(r.f)(i,l.basePath+"#"+t.slug)):h,p="external"===l.type?function(t,e,n){return t("a",{attrs:{href:e,target:"_blank",rel:"noopener noreferrer"},class:{"sidebar-link":!0}},[n,t("OutboundLink")])}(t,l.path,l.title||l.path):a(t,l.path,l.title||l.path,f),g=[e.frontmatter.sidebarDepth,c,s.sidebarDepth,o.sidebarDepth,1].find(t=>void 0!==t),d=s.displayAllHeaders||o.displayAllHeaders;if("auto"===l.type)return[p,u(t,l.children,l.basePath,i,g)];if((f||d)&&l.headers&&!r.e.test(l.path)){return[p,u(t,Object(r.d)(l.headers),l.path,i,g)]}return p}};n(330);function c(t,e){return"group"===e.type&&e.children.some(e=>"group"===e.type?c(t,e):"page"===e.type&&Object(r.f)(t,e.path))}var h={name:"SidebarLinks",components:{SidebarGroup:s,SidebarLink:Object(o.a)(l,void 0,void 0,!1,null,null,null).exports},props:["items","depth","sidebarDepth","initialOpenGroupIndex"],data(){return{openGroupIndex:this.initialOpenGroupIndex||0}},created(){this.refreshIndex()},watch:{$route(){this.refreshIndex()}},methods:{refreshIndex(){const t=function(t,e){for(let n=0;n-1&&(this.openGroupIndex=t)},toggleGroup(t){this.openGroupIndex=t===this.openGroupIndex?-1:t},isActive(t){return Object(r.f)(this.$route,t.regularPath)}}},f=Object(o.a)(h,(function(){var t=this,e=t._self._c;return t.items.length?e("ul",{staticClass:"sidebar-links"},t._l(t.items,(function(n,r){return e("li",{key:r},["group"===n.type?e("SidebarGroup",{attrs:{item:n,open:r===t.openGroupIndex,collapsable:n.collapsable||n.collapsible,depth:t.depth},on:{toggle:function(e){return t.toggleGroup(r)}}}):e("SidebarLink",{attrs:{sidebarDepth:t.sidebarDepth,item:n}})],1)})),0):t._e()}),[],!1,null,null,null);e.default=f.exports},function(t,e,n){"use strict";var r={name:"DropdownTransition",methods:{setHeight(t){t.style.height=t.scrollHeight+"px"},unsetHeight(t){t.style.height=""}}},i=(n(315),n(4)),o=Object(i.a)(r,(function(){return(0,this._self._c)("transition",{attrs:{name:"dropdown"},on:{enter:this.setHeight,"after-enter":this.unsetHeight,"before-leave":this.setHeight}},[this._t("default")],2)}),[],!1,null,null,null);e.a=o.exports},,function(t,e,n){"use strict";n(257)},function(t,e,n){"use strict";n(258)},function(t,e,n){"use strict";n(259)},function(t,e,n){"use strict";n(260)},function(t,e,n){"use strict";n(261)},function(t,e,n){"use strict";n(262)},function(t,e,n){"use strict";n(263)},function(t,e,n){"use strict";n(264)},function(t,e,n){"use strict";var r=n(5),i=n(2),o=n(302),s=URLSearchParams.prototype,a=i(s.forEach);r&&!("size"in s)&&o(s,"size",{get:function(){var t=0;return a(this,(function(){t++})),t},configurable:!0,enumerable:!0})},function(t,e,n){var r=n(101),i=n(13);t.exports=function(t,e,n){return n.get&&r(n.get,e,{getter:!0}),n.set&&r(n.set,e,{setter:!0}),i.f(t,e,n)}},function(t,e,n){"use strict";var r=n(18),i=n(304).findLastIndex,o=n(307);r({target:"Array",proto:!0},{findLastIndex:function(t){return i(this,t,arguments.length>1?arguments[1]:void 0)}}),o("findLastIndex")},function(t,e,n){var r=n(305),i=n(48),o=n(33),s=n(34),a=function(t){var e=1==t;return function(n,a,u){for(var l,c=o(n),h=i(c),f=r(a,u),p=s(h);p-- >0;)if(f(l=h[p],p,c))switch(t){case 0:return l;case 1:return p}return e?-1:void 0}};t.exports={findLast:a(0),findLastIndex:a(1)}},function(t,e,n){var r=n(306),i=n(32),o=n(29),s=r(r.bind);t.exports=function(t,e){return i(t),void 0===e?t:o?s(t,e):function(){return t.apply(e,arguments)}}},function(t,e,n){var r=n(19),i=n(2);t.exports=function(t){if("Function"===r(t))return i(t)}},function(t,e,n){var r=n(20),i=n(308),o=n(13).f,s=r("unscopables"),a=Array.prototype;null==a[s]&&o(a,s,{configurable:!0,value:i(null)}),t.exports=function(t){a[s][t]=!0}},function(t,e,n){var r,i=n(28),o=n(309),s=n(98),a=n(49),u=n(311),l=n(99),c=n(102),h=c("IE_PROTO"),f=function(){},p=function(t){return" + + diff --git a/favicon.ico b/favicon.ico new file mode 100644 index 00000000..51e9bfa0 Binary files /dev/null and b/favicon.ico differ diff --git a/img/bg.gif b/img/bg.gif new file mode 100644 index 00000000..d4bf3c41 Binary files /dev/null and b/img/bg.gif differ diff --git a/img/dunwu-logo.png b/img/dunwu-logo.png new file mode 100644 index 00000000..61570e2a Binary files /dev/null and b/img/dunwu-logo.png differ diff --git a/img/favicon.ico b/img/favicon.ico new file mode 100644 index 00000000..51e9bfa0 Binary files /dev/null and b/img/favicon.ico differ diff --git a/img/more.png b/img/more.png new file mode 100644 index 00000000..830613ba Binary files /dev/null and b/img/more.png differ diff --git a/img/other.png b/img/other.png new file mode 100644 index 00000000..87f80989 Binary files /dev/null and b/img/other.png differ diff --git a/index.html b/index.html new file mode 100644 index 00000000..28494535 --- /dev/null +++ b/index.html @@ -0,0 +1,81 @@ + + + + + + DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL

star fork build code style

💾 db-tutorial 是一个数据库教程。

# 数据库综合

# 分布式存储原理

# 分布式理论

# 分布式关键技术

# 流量调度
# 数据调度

# 其他

# 数据库中间件

# 关系型数据库

关系型数据库 整理主流关系型数据库知识点。

# 关系型数据库综合

# Mysql

img

# 其他

# 文档数据库

# MongoDB

MongoDB 是一个基于文档的分布式数据库，由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。

MongoDB 是一个介于关系型数据库和非关系型数据库之间的产品。它是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似 json 的 bson 格式，因此可以存储比较复杂的数据类型。

MongoDB 最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

# KV 数据库

# Redis

img

# 列式数据库

# HBase

# 搜索引擎数据库

# Elasticsearch

Elasticsearch 是一个基于 Lucene 的搜索和数据分析工具，它提供了一个分布式服务。Elasticsearch 是遵从 Apache 开源条款的一款开源产品，是当前主流的企业级搜索引擎。

# Elastic

# 资料 📚

# 数据库综合资料

# 关系型数据库资料

# Mysql 资料

# Nosql 数据库综合

选 SQL 还是 NoSQL，这里有两篇文章，值得你看看。

# 列式数据库资料

# Cassandra 资料

# HBase 资料

针对于 HBase 有两本书你可以考虑一下。

# KV 数据库资料

# Redis 资料

# 文档数据库资料

# MongoDB 资料

# 搜索引擎数据库资料

# ElasticSearch

# 图数据库

# 时序数据库

# 传送 🚪

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

文章分类
+ 数据库 + 87 + 列式数据库 + 13 + HBase + 12 + 关系型数据库 + 21 + 综合 + 6 + 搜索引擎数据库 + 24 + Elasticsearch + 16 + 数据库综合 + 3 + 数据库中间件 + 4 + 其他 + 4 更多 ...
热门标签
大数据 HBase API 数据库 列式数据库 关系型数据库 SQL 搜索引擎数据库 Elasticsearch 索引 综合 中间件 Elastic 数据结构 集群 分片 高亮 分词 性能 排序 聚合 查询 分库分表 文档数据库 MongoDB 事务 复制 Mysql FAQ 建模 更多...
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/markmap/01.html b/markmap/01.html new file mode 100644 index 00000000..c4e0bdbc --- /dev/null +++ b/markmap/01.html @@ -0,0 +1,113 @@ + + + + + + + Markmap + + + + + + + + + diff --git a/pages/002159/index.html b/pages/002159/index.html new file mode 100644 index 00000000..8b826ea4 --- /dev/null +++ b/pages/002159/index.html @@ -0,0 +1,91 @@ + + + + + + Elastic 技术栈之 Kibana | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-16
目录

Elastic 技术栈之 Kibana

# Elastic 技术栈之 Kibana

# Discover

单击侧面导航栏中的 Discover ，可以显示 Kibana 的数据查询功能功能。

img

在搜索栏中，您可以输入 Elasticsearch 查询条件来搜索您的数据。您可以在 Discover 页面中浏览结果并在 Visualize 页面中创建已保存搜索条件的可视化。

当前索引模式显示在查询栏下方。索引模式确定提交查询时搜索哪些索引。要搜索一组不同的索引，请从下拉菜单中选择不同的模式。要添加索引模式（index pattern），请转至 Management/Kibana/Index Patterns 并单击 Add New。

您可以使用字段名称和您感兴趣的值构建搜索。对于数字字段，可以使用比较运算符，如大于（>），小于（<）或等于（=）。您可以将元素与逻辑运算符 AND，OR 和 NOT 链接，全部使用大写。

默认情况下，每个匹配文档都显示所有字段。要选择要显示的文档字段，请将鼠标悬停在“可用字段”列表上，然后单击要包含的每个字段旁边的添加按钮。例如，如果只添加 account_number，则显示将更改为包含五个帐号的简单列表：

img

# 查询语义

kibana 的搜索栏遵循 query-string-syntax (opens new window) 文档中所说明的查询语义。

这里说明一些最基本的查询语义。

查询字符串会被解析为一系列的术语和运算符。一个术语可以是一个单词（如：quick、brown）或用双引号包围的短语（如"quick brown"）。

查询操作允许您自定义搜索 - 下面介绍了可用的选项。

# 字段名称

正如查询字符串查询中所述，将在搜索条件中搜索 default_field，但可以在查询语法中指定其他字段：

例如：

  • 查询 status 字段中包含 active 关键字
status:active
+
  • title 字段包含 quick 或 brown 关键字。如果您省略 OR 运算符，则将使用默认运算符
title:(quick OR brown)
+title:(quick brown)
+
  • author 字段查找精确的短语 "john smith"，即精确查找。
author:"John Smith"
+
  • 任意字段 book.title，book.content 或 book.date 都包含 quick 或 brown（注意我们需要如何使用 \* 表示通配符）
book.\*:(quick brown)
+
  • title 字段包含任意非 null 值
_exists_:title
+

# 通配符

ELK 提供了 ? 和 * 两个通配符。

  • ? 表示任意单个字符；
  • * 表示任意零个或多个字符。
qu?ck bro*
+

注意：通配符查询会使用大量的内存并且执行性能较为糟糕，所以请慎用。 > 提示：纯通配符 * 被写入 exsits (opens new window) 查询，从而提高了查询效率。因此，通配符 field：* 将匹配包含空值的文档，如：{“field”：“”}，但是如果字段丢失或显示将值置为 null 则不匹配，如：“field”：null} > 提示：在一个单词的开头（例如：*ing）使用通配符这种方式的查询量特别大，因为索引中的所有术语都需要检查，以防万一匹配。通过将 allow_leading_wildcard 设置为 false，可以禁用。

# 正则表达式

可以通过 / 将正则表达式包裹在查询字符串中进行查询

例：

name:/joh?n(ath[oa]n)/
+

支持的正则表达式语义可以参考：Regular expression syntax (opens new window)

# 模糊查询

我们可以使用 ~ 运算符来进行模糊查询。

例：

假设我们实际想查询

quick brown forks
+

但是，由于拼写错误，我们的查询关键字变成如下情况，依然可以查到想要的结果。

quikc\~ brwn\~ foks\~
+

这种模糊查询使用 Damerau-Levenshtein 距离来查找所有匹配最多两个更改的项。所谓的更改是指单个字符的插入，删除或替换，或者两个相邻字符的换位。

默认编辑距离为 2，但编辑距离为 1 应足以捕捉所有人类拼写错误的 80％。它可以被指定为：

quikc\~1
+

# 近似检索

尽管短语查询（例如，john smith）期望所有的词条都是完全相同的顺序，但是近似查询允许指定的单词进一步分开或以不同的顺序排列。与模糊查询可以为单词中的字符指定最大编辑距离一样，近似搜索也允许我们指定短语中单词的最大编辑距离：

例

"fox quick"\~5
+

字段中的文本越接近查询字符串中指定的原始顺序，该文档就越被认为是相关的。当与上面的示例查询相比时，短语 "quick fox" 将被认为比 "quick brown fox" 更近似查询条件。

# 范围

可以为日期，数字或字符串字段指定范围。闭区间范围用方括号 [min TO max] 和开区间范围用花括号 {min TO max} 来指定。

我们不妨来看一些示例。

  • 2012 年的所有日子
date:[2012-01-01 TO 2012-12-31]
+
  • 数字 1 到 5
count:[1 TO 5]
+
  • 在 alpha 和 omega 之间的标签，不包括 alpha 和 omega
tag:{alpha TO omega}
+
  • 10 以上的数字
count:[10 TO *]
+
  • 2012 年以前的所有日期
date:{* TO 2012-01-01}
+

此外，开区间和闭区间也可以组合使用

  • 数组 1 到 5，但不包括 5
count:[1 TO 5}
+

一边无界的范围也可以使用以下语法：

age:>10
+age:>=10
+age:<10
+age:<=10
+

当然，你也可以使用 AND 运算符来得到连个查询结果的交集

age:(>=10 AND <20)
+age:(+>=10 +<20)
+

# Boosting

使用操作符 ^ 使一个术语比另一个术语更相关。例如，如果我们想查找所有有关狐狸的文档，但我们对狐狸特别感兴趣：

quick^2 fox
+

默认提升值是 1，但可以是任何正浮点数。 0 到 1 之间的提升减少了相关性。

增强也可以应用于短语或组：

"john smith"^2   (foo bar)^4
+

# 布尔操作

默认情况下，只要一个词匹配，所有词都是可选的。搜索 foo bar baz 将查找包含 foo 或 bar 或 baz 中的一个或多个的任何文档。我们已经讨论了上面的default_operator，它允许你强制要求所有的项，但也有布尔运算符可以在查询字符串本身中使用，以提供更多的控制。

首选的操作符是 +（此术语必须存在）和 - （此术语不得存在）。所有其他条款是可选的。例如，这个查询：

quick brown +fox -news
+

这条查询意味着：

  • fox 必须存在
  • news 必须不存在
  • quick 和 brown 是可有可无的

熟悉的运算符 AND，OR 和 NOT（也写成 &&，|| 和 !）也被支持。然而，这些操作符有一定的优先级：NOT 优先于 AND，AND 优先于 OR。虽然 + 和 - 仅影响运算符右侧的术语，但 AND 和 OR 会影响左侧和右侧的术语。

# 分组

多个术语或子句可以用圆括号组合在一起，形成子查询

(quick OR brown) AND fox
+

可以使用组来定位特定的字段，或者增强子查询的结果：

status:(active OR pending) title:(full text search)^2
+

# 保留字

如果你需要使用任何在你的查询本身中作为操作符的字符（而不是作为操作符），那么你应该用一个反斜杠来转义它们。例如，要搜索（1 + 1）= 2，您需要将查询写为 \(1\+1\)\=2

保留字符是：+ - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /

无法正确地转义这些特殊字符可能会导致语法错误，从而阻止您的查询运行。

# 空查询

如果查询字符串为空或仅包含空格，则查询将生成一个空的结果集。

# Visualize

要想使用可视化的方式展示您的数据，请单击侧面导航栏中的 Visualize。

Visualize 工具使您能够以多种方式（如饼图、柱状图、曲线图、分布图等）查看数据。要开始使用，请点击蓝色的 Create a visualization 或 + 按钮。

https://www.elastic.co/guide/en/kibana/6.1/images/tutorial-visualize-landing.png

有许多可视化类型可供选择。

https://www.elastic.co/guide/en/kibana/6.1/images/tutorial-visualize-wizard-step-1.png

下面，我们来看创建几个图标示例：

# Pie

您可以从保存的搜索中构建可视化文件，也可以输入新的搜索条件。要输入新的搜索条件，首先需要选择一个索引模式来指定要搜索的索引。

默认搜索匹配所有文档。最初，一个“切片”包含整个饼图：

https://www.elastic.co/guide/en/kibana/6.1/images/tutorial-visualize-pie-1.png

要指定在图表中展示哪些数据，请使用 Elasticsearch 存储桶聚合。分组汇总只是将与您的搜索条件相匹配的文档分类到不同的分类中，也称为分组。

为每个范围定义一个存储桶：

  1. 单击 Split Slices。
  2. 在 Aggregation 列表中选择 Terms。注意：这里的 Terms 是 Elk 采集数据时定义好的字段或标签。
  3. 在 Field 列表中选择 level.keyword。
  4. 点击 images/apply-changes-button.png 按钮来更新图表。

image.png

完成后，如果想要保存这个图表，可以点击页面最上方一栏中的 Save 按钮。

# Vertical Bar

我们在展示一下如何创建柱状图。

  1. 点击蓝色的 Create a visualization 或 + 按钮。选择 Vertical Bar
  2. 选择索引模式。由于您尚未定义任何 bucket ，因此您会看到一个大栏，显示与默认通配符查询匹配的文档总数。
  3. 指定 Y 轴所代表的字段
  4. 指定 X 轴所代表的字段
  5. 点击 images/apply-changes-button.png 按钮来更新图表。

image.png

完成后，如果想要保存这个图表，可以点击页面最上方一栏中的 Save 按钮。

# Dashboard

Dashboard 可以整合和共享 Visualize 集合。

  1. 点击侧面导航栏中的 Dashboard。
  2. 点击添加显示保存的可视化列表。
  3. 点击之前保存的 Visualize，然后点击列表底部的小向上箭头关闭可视化列表。
  4. 将鼠标悬停在可视化对象上会显示允许您编辑，移动，删除和调整可视化对象大小的容器控件。
+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elastic#Kibana
上次更新: 2023/06/29, 22:27:04
Filebeat 运维
Kibana 运维

+ ← + Kibana 运维→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/00b04d/index.html b/pages/00b04d/index.html new file mode 100644 index 00000000..d47d2cc9 --- /dev/null +++ b/pages/00b04d/index.html @@ -0,0 +1,116 @@ + + + + + + Mysql 事务 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-03
目录

Mysql 事务

# Mysql 事务

不是所有的 Mysql 存储引擎都实现了事务处理。支持事务的存储引擎有：InnoDB 和 NDB Cluster。不支持事务的存储引擎，代表有：MyISAM。

用户可以根据业务是否需要事务处理（事务处理可以保证数据安全，但会增加系统开销），选择合适的存储引擎。

img

# 事务简介

事务简单来说：一个 Session 中所进行所有的操作，要么同时成功，要么同时失败。进一步说，事务指的是满足 ACID 特性的一组操作，可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。

img

事务就是一组原子性的 SQL 语句。具体来说，事务指的是满足 ACID 特性的一组操作。

事务内的 SQL 语句，要么全执行成功，要么全执行失败。

通过加锁的方式，可以实现不同的事务隔离机制。

想象一下，如果没有事务，在并发环境下，就可能出现丢失修改的问题。

T1 和 T2 两个线程都对一个数据进行修改，T1 先修改，T2 随后修改，T2 的修改覆盖了 T1 的修改。

img

# 事务用法

# 事务处理指令

Mysql 中，使用 START TRANSACTION 语句开始一个事务；使用 COMMIT 语句提交所有的修改；使用 ROLLBACK 语句撤销所有的修改。不能回退 SELECT 语句，回退 SELECT 语句也没意义；也不能回退 CREATE 和 DROP 语句。

  • START TRANSACTION - 指令用于标记事务的起始点。
  • SAVEPOINT - 指令用于创建保留点。
  • ROLLBACK TO - 指令用于回滚到指定的保留点；如果没有设置保留点，则回退到 START TRANSACTION 语句处。
  • COMMIT - 提交事务。

事务处理示例：

（1）创建一张示例表

-- 撤销表 user
+DROP TABLE IF EXISTS user;
+
+-- 创建表 user
+CREATE TABLE user (
+  id int(10) unsigned NOT NULL COMMENT 'Id',
+  username varchar(64) NOT NULL DEFAULT 'default' COMMENT '用户名',
+  password varchar(64) NOT NULL DEFAULT 'default' COMMENT '密码',
+  email varchar(64) NOT NULL DEFAULT 'default' COMMENT '邮箱'
+) COMMENT='用户表';
+

（2）执行事务操作

-- 开始事务
+START TRANSACTION;
+
+-- 插入操作 A
+INSERT INTO `user`
+VALUES (1, 'root1', 'root1', 'xxxx@163.com');
+
+-- 创建保留点 updateA
+SAVEPOINT updateA;
+
+-- 插入操作 B
+INSERT INTO `user`
+VALUES (2, 'root2', 'root2', 'xxxx@163.com');
+
+-- 回滚到保留点 updateA
+ROLLBACK TO updateA;
+
+-- 提交事务，只有操作 A 生效
+COMMIT;
+

（3）执行结果

SELECT * FROM user;
+

结果：

1	root1	root1	xxxx@163.com
+

# AUTOCOMMIT

MySQL 默认采用隐式提交策略（autocommit）。每执行一条语句就把这条语句当成一个事务然后进行提交。当出现 START TRANSACTION 语句时，会关闭隐式提交；当 COMMIT 或 ROLLBACK 语句执行后，事务会自动关闭，重新恢复隐式提交。

通过 set autocommit=0 可以取消自动提交，直到 set autocommit=1 才会提交；autocommit 标记是针对每个连接而不是针对服务器的。

-- 查看 AUTOCOMMIT
+SHOW VARIABLES LIKE 'AUTOCOMMIT';
+
+-- 关闭 AUTOCOMMIT
+SET autocommit = 0;
+
+-- 开启 AUTOCOMMIT
+SET autocommit = 1;
+

# ACID

ACID 是数据库事务正确执行的四个基本要素。

  • 原子性（Atomicity）
    • 事务被视为不可分割的最小单元，事务中的所有操作要么全部提交成功，要么全部失败回滚。
    • 回滚可以用日志来实现，日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。
  • 一致性（Consistency）
    • 数据库在事务执行前后都保持一致性状态。
    • 在一致性状态下，所有事务对一个数据的读取结果都是相同的。
  • 隔离性（Isolation）
    • 一个事务所做的修改在最终提交以前，对其它事务是不可见的。
  • 持久性（Durability）
    • 一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。
    • 可以通过数据库备份和恢复来实现，在系统发生奔溃时，使用备份的数据库进行数据恢复。

一个支持事务（Transaction）中的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易。

  • 只有满足一致性，事务的执行结果才是正确的。
  • 在无并发的情况下，事务串行执行，隔离性一定能够满足。此时只要能满足原子性，就一定能满足一致性。
  • 在并发的情况下，多个事务并行执行，事务不仅要满足原子性，还需要满足隔离性，才能满足一致性。
  • 事务满足持久化是为了能应对系统崩溃的情况。

img

MySQL 默认采用自动提交模式（AUTO COMMIT）。也就是说，如果不显式使用 START TRANSACTION 语句来开始一个事务，那么每个查询操作都会被当做一个事务并自动提交。

# 事务隔离级别

# 事务隔离简介

在并发环境下，事务的隔离性很难保证，因此会出现很多并发一致性问题：

  • 丢失修改
  • 脏读
  • 不可重复读
  • 幻读

在 SQL 标准中，定义了四种事务隔离级别（级别由低到高）：

  • 读未提交
  • 读提交
  • 可重复读
  • 串行化

Mysql 中查看和设置事务隔离级别：

-- 查看事务隔离级别
+SHOW VARIABLES LIKE 'transaction_isolation';
+
+-- 设置事务隔离级别为 READ UNCOMMITTED
+SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
+
+-- 设置事务隔离级别为 READ COMMITTED
+SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
+
+-- 设置事务隔离级别为 REPEATABLE READ
+SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
+
+-- 设置事务隔离级别为 SERIALIZABLE
+SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
+

# 读未提交

读未提交（read uncommitted） 是指：事务中的修改，即使没有提交，对其它事务也是可见的。

读未提交的问题：事务可以读取未提交的数据，也被称为 脏读（Dirty Read）。

T1 修改一个数据，T2 随后读取这个数据。如果 T1 撤销了这次修改，那么 T2 读取的数据是脏数据。

img

# 读提交

读提交（read committed） 是指：事务提交后，其他事务才能看到它的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的。读提交解决了脏读的问题。

读提交是大多数数据库的默认事务隔离级别。

读提交有时也叫不可重复读，它的问题是：执行两次相同的查询，得到的结果可能不一致。

T2 读取一个数据，T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。

img

# 可重复读

可重复读（REPEATABLE READ） 是指：保证在同一个事务中多次读取同样数据的结果是一样的。可重复读解决了不可重复读问题。

可重复读是 Mysql 的默认事务隔离级别。

可重复读的问题：事务 T1 读取某个范围内的记录时，事务 T2 在该范围内插入了新的记录，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同，即为 幻读（Phantom Read）。

img

# 串行化

串行化（SERIALIXABLE） 是指：强制事务串行执行，对于同一行记录，加读写锁，一旦出现锁冲突，必须等前面的事务释放锁。

强制事务串行执行，则避免了所有的并发问题。串行化策略会在读取的每一行数据上都加锁，这可能导致大量的超时和锁竞争。这对于高并发应用基本上是不可接受的，所以一般不会采用这个级别。

# 隔离级别小结

  • 读未提交（READ UNCOMMITTED） - 事务中的修改，即使没有提交，对其它事务也是可见的。
  • 读提交（READ COMMITTED） - 一个事务只能读取已经提交的事务所做的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的。
  • 重复读（REPEATABLE READ） - 保证在同一个事务中多次读取同样数据的结果是一样的。
  • 串行化（SERIALIXABLE） - 对于同一行记录，加读写锁，一旦出现锁冲突，必须等前面的事务释放锁。

数据库隔离级别解决的问题：

隔离级别 丢失修改 脏读 不可重复读 幻读
读未提交 ✔️ ❌ ❌ ❌
读提交 ✔️ ✔️ ❌ ❌
可重复读 ✔️ ✔️ ✔️ ❌
可串行化 ✔️ ✔️ ✔️ ✔️

# 死锁

死锁是指两个或多个事务竞争同一资源，并请求锁定对方占用的资源，从而导致恶性循环的现象。

产生死锁的场景：

  • 当多个事务试图以不同的顺序锁定资源时，就可能会产生死锁。

  • 多个事务同时锁定同一个资源时，也会产生死锁。

# 死锁的原因

行锁的具体实现算法有三种：record lock、gap lock 以及 next-key lock。record lock 是专门对索引项加锁；gap lock 是对索引项之间的间隙加锁；next-key lock 则是前面两种的组合，对索引项以其之间的间隙加锁。

只在可重复读或以上隔离级别下的特定操作才会取得 gap lock 或 next-key lock，在 Select、Update 和 Delete 时，除了基于唯一索引的查询之外，其它索引查询时都会获取 gap lock 或 next-key lock，即锁住其扫描的范围。主键索引也属于唯一索引，所以主键索引是不会使用 gap lock 或 next-key lock。

在 MySQL 中，gap lock 默认是开启的，即 innodb_locks_unsafe_for_binlog 参数值是 disable 的，且 MySQL 中默认的是 RR 事务隔离级别。

当我们执行以下查询 SQL 时，由于 order_no 列为非唯一索引，此时又是 RR 事务隔离级别，所以 SELECT 的加锁类型为 gap lock，这里的 gap 范围是 (4,+∞）。

SELECT id FROM demo.order_record where order_no = 4 for update;

执行查询 SQL 语句获取的 gap lock 并不会导致阻塞，而当我们执行以下插入 SQL 时，会在插入间隙上再次获取插入意向锁。插入意向锁其实也是一种 gap 锁，它与 gap lock 是冲突的，所以当其它事务持有该间隙的 gap lock 时，需要等待其它事务释放 gap lock 之后，才能获取到插入意向锁。

以上事务 A 和事务 B 都持有间隙 (4,+∞）的 gap 锁，而接下来的插入操作为了获取到插入意向锁，都在等待对方事务的 gap 锁释放，于是就造成了循环等待，导致死锁。

INSERT INTO demo.order_record(order_no, status, create_date) VALUES (5, 1, ‘2019-07-13 10:57:03’);

img

另一个死锁场景

InnoDB 存储引擎的主键索引为聚簇索引，其它索引为辅助索引。如果使用辅助索引来更新数据库，就需要使用聚簇索引来更新数据库字段。如果两个更新事务使用了不同的辅助索引，或一个使用了辅助索引，一个使用了聚簇索引，就都有可能导致锁资源的循环等待。由于本身两个事务是互斥，也就构成了以上死锁的四个必要条件了。

img

出现死锁的步骤：

img

综上可知，在更新操作时，我们应该尽量使用主键来更新表字段，这样可以有效避免一些不必要的死锁发生。

# 避免死锁

预防死锁的注意事项：

  • 在编程中尽量按照固定的顺序来处理数据库记录，假设有两个更新操作，分别更新两条相同的记录，但更新顺序不一样，有可能导致死锁；
  • 在允许幻读和不可重复读的情况下，尽量使用 RC 事务隔离级别，可以避免 gap lock 导致的死锁问题；
  • 更新表时，尽量使用主键更新；
  • 避免长事务，尽量将长事务拆解，可以降低与其它事务发生冲突的概率；
  • 设置合理的锁等待超时参数，我们可以通过 innodb_lock_wait_timeout 设置合理的等待超时阈值，特别是在一些高并发的业务中，我们可以尽量将该值设置得小一些，避免大量事务等待，占用系统资源，造成严重的性能开销。

另外，我们还可以将 order_no 列设置为唯一索引列。虽然不能防止幻读，但我们可以利用它的唯一性来保证订单记录不重复创建，这种方式唯一的缺点就是当遇到重复创建订单时会抛出异常。

我们还可以使用其它的方式来代替数据库实现幂等性校验。例如，使用 Redis 以及 ZooKeeper 来实现，运行效率比数据库更佳。

# 解决死锁

当出现死锁以后，有两种策略：

  • 一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout 来设置。
  • 另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

在 InnoDB 中，innodb_lock_wait_timeout 的默认值是 50s，意味着如果采用第一个策略，当出现死锁以后，第一个被锁住的线程要过 50s 才会超时退出，然后其他线程才有可能继续执行。对于在线服务来说，这个等待时间往往是无法接受的。

但是，我们又不可能直接把这个时间设置成一个很小的值，比如 1s。这样当出现死锁的时候，确实很快就可以解开，但如果不是死锁，而是简单的锁等待呢？所以，超时时间设置太短的话，会出现很多误伤。

所以，正常情况下我们还是要采用第二种策略，即：主动死锁检测，而且 innodb_deadlock_detect 的默认值本身就是 on。为了解决死锁问题，不同数据库实现了各自的死锁检测和超时机制。InnoDB 的处理策略是：将持有最少行级排它锁的事务进行回滚。

主动死锁检测在发生死锁的时候，是能够快速发现并进行处理的，但是它也是有额外负担的。你可以想象一下这个过程：每当一个事务被锁的时候，就要看看它所依赖的线程有没有被别人锁住，如此循环，最后判断是否出现了循环等待，也就是死锁。

# 分布式事务

在单一数据节点中，事务仅限于对单一数据库资源的访问控制，称之为 本地事务。几乎所有的成熟的关系型数据库都提供了对本地事务的原生支持。

分布式事务指的是事务操作跨越多个节点，并且要求满足事务的 ACID 特性。

分布式事务的常见方案如下：

  • 两阶段提交（2PC） - 将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
  • 三阶段提交（3PC） - 与二阶段提交不同的是，引入超时机制。同时在协调者和参与者中都引入超时机制。将二阶段的准备阶段拆分为 2 个阶段，插入了一个 preCommit 阶段，使得原先在二阶段提交中，参与者在准备之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。
  • 补偿事务（TCC）
    • Try - 操作作为一阶段，负责资源的检查和预留。
    • Confirm - 操作作为二阶段提交操作，执行真正的业务。
    • Cancel - 是预留资源的取消。
  • 本地消息表 - 在事务主动发起方额外新建事务消息表，事务发起方处理业务和记录事务消息在本地事务中完成，轮询事务消息表的数据发送事务消息，事务被动方基于消息中间件消费事务消息表中的事务。
  • MQ 事务 - 基于 MQ 的分布式事务方案其实是对本地消息表的封装。
  • SAGA - Saga 事务核心思想是将长事务拆分为多个本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。

分布式事务方案分析：

  • 2PC/3PC 依赖于数据库，能够很好的提供强一致性和强事务性，但相对来说延迟比较高，比较适合传统的单体应用，在同一个方法中存在跨库操作的情况，不适合高并发和高性能要求的场景。
  • TCC 适用于执行时间确定且较短，实时性要求高，对数据一致性要求高，比如互联网金融企业最核心的三个服务：交易、支付、账务。
  • 本地消息表/MQ 事务 都适用于事务中参与方支持操作幂等，对一致性要求不高，业务上能容忍数据不一致到一个人工检查周期，事务涉及的参与方、参与环节较少，业务上有对账/校验系统兜底。
  • Saga 事务 由于 Saga 事务不能保证隔离性，需要在业务层控制并发，适合于业务场景事务并发操作同一资源较少的情况。 Saga 相比缺少预提交动作，导致补偿动作的实现比较麻烦，例如业务是发送短信，补偿动作则得再发送一次短信说明撤销，用户体验比较差。Saga 事务较适用于补偿动作容易处理的场景。

分布式事务详细说明、分析请参考：分布式事务基本原理 (opens new window)

# 事务最佳实践

高并发场景下的事务到底该如何调优？

# 尽量使用低级别事务隔离

结合业务场景，尽量使用低级别事务隔离

# 避免行锁升级表锁

在 InnoDB 中，行锁是通过索引实现的，如果不通过索引条件检索数据，行锁将会升级到表锁。我们知道，表锁是会严重影响到整张表的操作性能的，所以应该尽力避免。

# 缩小事务范围

有时候，数据库并发访问量太大，会出现以下异常：

MySQLQueryInterruptedException: Query execution was interrupted
+

高并发时对一条记录进行更新的情况下，由于更新记录所在的事务还可能存在其他操作，导致一个事务比较长，当有大量请求进入时，就可能导致一些请求同时进入到事务中。

又因为锁的竞争是不公平的，当多个事务同时对一条记录进行更新时，极端情况下，一个更新操作进去排队系统后，可能会一直拿不到锁，最后因超时被系统打断踢出。

img

如上图中的操作，虽然都是在一个事务中，但锁的申请在不同时间，只有当其他操作都执行完，才会释放所有锁。因为扣除库存是更新操作，属于行锁，这将会影响到其他操作该数据的事务，所以我们应该尽量避免长时间地持有该锁，尽快释放该锁。又因为先新建订单和先扣除库存都不会影响业务，所以我们可以将扣除库存操作放到最后，也就是使用执行顺序 1，以此尽量减小锁的持有时间。

在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。

知道了这个设定，对我们使用事务有什么帮助呢？那就是，如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#Mysql#事务
上次更新: 2023/06/29, 22:27:04
MySQL 工作流
Mysql 锁

+ ← + Mysql 锁→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/012488/index.html b/pages/012488/index.html new file mode 100644 index 00000000..e7381583 --- /dev/null +++ b/pages/012488/index.html @@ -0,0 +1,69 @@ + + + + + + 数据库 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-02-22
目录

数据库

logo

star fork build code style

DB-TUTORIAL

💾 db-tutorial 是一个数据库教程。

# 数据库综合

# 分布式存储原理

# 分布式理论

# 分布式关键技术

# 流量调度
# 数据调度

# 其他

# 数据库中间件

# 关系型数据库

关系型数据库 整理主流关系型数据库知识点。

# 关系型数据库综合

# Mysql

img

# 其他

# 文档数据库

# MongoDB

MongoDB 是一个基于文档的分布式数据库，由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。

MongoDB 是一个介于关系型数据库和非关系型数据库之间的产品。它是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似 json 的 bson 格式，因此可以存储比较复杂的数据类型。

MongoDB 最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

# KV 数据库

# Redis

img

# 列式数据库

# HBase

# 搜索引擎数据库

# Elasticsearch

Elasticsearch 是一个基于 Lucene 的搜索和数据分析工具，它提供了一个分布式服务。Elasticsearch 是遵从 Apache 开源条款的一款开源产品，是当前主流的企业级搜索引擎。

# Elastic

# 资料 📚

# 数据库综合资料

# 关系型数据库资料

# Mysql 资料

# Nosql 数据库综合

选 SQL 还是 NoSQL，这里有两篇文章，值得你看看。

# 列式数据库资料

# Cassandra 资料

# HBase 资料

针对于 HBase 有两本书你可以考虑一下。

# KV 数据库资料

# Redis 资料

# 文档数据库资料

# MongoDB 资料

# 搜索引擎数据库资料

# ElasticSearch

# 图数据库

# 时序数据库

# 传送 🚪

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/0cb563/index.html b/pages/0cb563/index.html new file mode 100644 index 00000000..8792c6a6 --- /dev/null +++ b/pages/0cb563/index.html @@ -0,0 +1,70 @@ + + + + + + Elasticsearch 面试总结 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-16
目录

Elasticsearch 面试总结

# Elasticsearch 面试总结

# 集群部署

ES 部署情况：

5 节点（配置：8 核 64 G 1T），总计 320 G，5 T。

约 10+ 索引，5 分片，每日新增数据量约为 2G，4000w 条。记录保存 30 天。

# 性能优化

# filesystem cache

你往 es 里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 里面去。

es-search-process (opens new window)

es 的搜索引擎严重依赖于底层的 filesystem cache ，你如果给 filesystem cache 更多的内存，尽量让内存可以容纳所有的 idx segment file索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。

性能差距究竟可以有多大？我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能绝对是秒级别的，1 秒、5 秒、10 秒。但如果是走 filesystem cache ，是走纯内存的，那么一般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。

这里有个真实的案例。某个公司 es 节点有 3 台机器，每台机器看起来内存很多，64G，总内存就是 64 * 3 = 192G 。每台机器给 es jvm heap 是 32G ，那么剩下来留给 filesystem cache 的就是每台机器才 32G ，总共集群里给 filesystem cache 的就是 32 * 3 = 96G 内存。而此时，整个磁盘上索引数据文件，在 3 台机器上一共占用了 1T 的磁盘容量，es 数据量是 1T ，那么每台机器的数据量是 300G 。这样性能好吗？ filesystem cache 的内存才 100G，十分之一的数据可以放内存，其他的都在磁盘，然后你执行搜索操作，大部分操作都是走磁盘，性能肯定差。

归根结底，你要让 es 性能要好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半。

根据我们自己的生产环境实践经验，最佳的情况下，是仅仅在 es 中就存少量的数据，就是你要用来搜索的那些索引，如果内存留给 filesystem cache 的是 100G，那么你就将索引数据控制在 100G 以内，这样的话，你的数据几乎全部走内存来搜索，性能非常之高，一般可以在 1 秒以内。

比如说你现在有一行数据。 id,name,age .... 30 个字段。但是你现在搜索，只需要根据 id,name,age 三个字段来搜索。如果你傻乎乎往 es 里写入一行数据所有的字段，就会导致说 90% 的数据是不用来搜索的，结果硬是占据了 es 机器上的 filesystem cache 的空间，单条数据的数据量越大，就会导致 filesystem cahce 能缓存的数据就越少。其实，仅仅写入 es 中要用来检索的少数几个字段就可以了，比如说就写入 es id,name,age 三个字段，然后你可以把其他的字段数据存在 mysql/hbase 里，我们一般是建议用 es + hbase 这么一个架构。

hbase 的特点是适用于海量数据的在线存储，就是对 hbase 可以写入海量数据，但是不要做复杂的搜索，做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。从 es 中根据 name 和 age 去搜索，拿到的结果可能就 20 个 doc id ，然后根据 doc id 到 hbase 里去查询每个 doc id 对应的完整的数据，给查出来，再返回给前端。

写入 es 的数据最好小于等于，或者是略微大于 es 的 filesystem cache 的内存容量。然后你从 es 检索可能就花费 20ms，然后再根据 es 返回的 id 去 hbase 里查询，查 20 条数据，可能也就耗费个 30ms，可能你原来那么玩儿，1T 数据都放 es，会每次查询都是 5~10s，现在可能性能就会很高，每次查询就是 50ms。

# 数据预热

假如说，哪怕是你就按照上述的方案去做了，es 集群中每个机器写入的数据量还是超过了 filesystem cache 一倍，比如说你写入一台机器 60G 数据，结果 filesystem cache 就 30G，还是有 30G 数据留在了磁盘上。

其实可以做数据预热。

举个例子，拿微博来说，你可以把一些大 V，平时看的人很多的数据，你自己提前后台搞个系统，每隔一会儿，自己的后台系统去搜索一下热数据，刷到 filesystem cache 里去，后面用户实际上来看这个热数据的时候，他们就是直接从内存里搜索了，很快。

或者是电商，你可以将平时查看最多的一些商品，比如说 iphone 8，热数据提前后台搞个程序，每隔 1 分钟自己主动访问一次，刷到 filesystem cache 里去。

对于那些你觉得比较热的、经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据每隔一段时间，就提前访问一下，让数据进入 filesystem cache 里面去。这样下次别人访问的时候，性能一定会好很多。

# 冷热分离

es 可以做类似于 mysql 的水平拆分，就是说将大量的访问很少、频率很低的数据，单独写一个索引，然后将访问很频繁的热数据单独写一个索引。最好是将冷数据写入一个索引中，然后热数据写入另外一个索引中，这样可以确保热数据在被预热之后，尽量都让他们留在 filesystem os cache 里，别让冷数据给冲刷掉。

你看，假设你有 6 台机器，2 个索引，一个放冷数据，一个放热数据，每个索引 3 个 shard。3 台机器放热数据 index，另外 3 台机器放冷数据 index。然后这样的话，你大量的时间是在访问热数据 index，热数据可能就占总数据量的 10%，此时数据量很少，几乎全都保留在 filesystem cache 里面了，就可以确保热数据的访问性能是很高的。但是对于冷数据而言，是在别的 index 里的，跟热数据 index 不在相同的机器上，大家互相之间都没什么联系了。如果有人访问冷数据，可能大量数据是在磁盘上的，此时性能差点，就 10% 的人去访问冷数据，90% 的人在访问热数据，也无所谓了。

# document 模型设计

对于 MySQL，我们经常有一些复杂的关联查询。在 es 里该怎么玩儿，es 里面的复杂的关联查询尽量别用，一旦用了性能一般都不太好。

最好是先在 Java 系统里就完成关联，将关联好的数据直接写入 es 中。搜索的时候，就不需要利用 es 的搜索语法来完成 join 之类的关联搜索了。

document 模型设计是非常重要的，很多操作，不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。es 能支持的操作就那么多，不要考虑用 es 做一些它不好操作的事情。如果真的有那种操作，尽量在 document 模型设计的时候，写入的时候就完成。另外对于一些太复杂的操作，比如 join/nested/parent-child 搜索都要尽量避免，性能都很差的。

# 分页性能优化

es 的分页是较坑的，为啥呢？举个例子吧，假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 shard 上存储的前 1000 条数据都查到一个协调节点上，如果你有个 5 个 shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到最终第 100 页的 10 条数据。

分布式的，你要查第 100 页的 10 条数据，不可能说从 5 个 shard，每个 shard 就查 2 条数据，最后到协调节点合并成 10 条数据吧？你必须得从每个 shard 都查 1000 条数据过来，然后根据你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第 100 页的数据。你翻页的时候，翻的越深，每个 shard 返回的数据就越多，而且协调节点处理的时间越长，非常坑爹。所以用 es 做分页的时候，你会发现越翻到后面，就越是慢。

我们之前也是遇到过这个问题，用 es 作分页，前几页就几十毫秒，翻到 10 页或者几十页的时候，基本上就要 5~10 秒才能查出来一页数据了。

有什么解决方案吗？

# 不允许深度分页（默认深度分页性能很差）

跟产品经理说，你系统不允许翻那么深的页，默认翻的越深，性能就越差。

# 类似于 app 里的推荐商品不断下拉出来一页一页的

类似于微博中，下拉刷微博，刷出来一页一页的，你可以用 scroll api ，关于如何使用，自行上网搜索。

scroll 会一次性给你生成所有数据的一个快照，然后每次滑动向后翻页就是通过游标 scroll_id 移动，获取下一页下一页这样子，性能会比上面说的那种分页性能要高很多很多，基本上都是毫秒级的。

但是，唯一的一点就是，这个适合于那种类似微博下拉翻页的，不能随意跳到任何一页的场景。也就是说，你不能先进入第 10 页，然后去第 120 页，然后又回到第 58 页，不能随意乱跳页。所以现在很多产品，都是不允许你随意翻页的，app，也有一些网站，做的就是你只能往下拉，一页一页的翻。

初始化时必须指定 scroll 参数，告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。

除了用 scroll api ，你也可以用 search_after 来做， search_after 的思想是使用前一页的结果来帮助检索下一页的数据，显然，这种方式也不允许你随意翻页，你只能一页页往后翻。初始化时，需要使用一个唯一值的字段作为 sort 字段。

1.1、设计阶段调优

（1）根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索引；

（2）使用别名进行索引管理；

（3）每天凌晨定时对索引做 force_merge 操作，以释放空间；

（4）采取冷热分离机制，热数据存储到 SSD，提高检索效率；冷数据定期进行 shrink 操作，以缩减存储；

（5）采取 curator 进行索引的生命周期管理；

（6）仅针对需要分词的字段，合理的设置分词器；

（7）Mapping 阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。……..

1.2、写入调优

（1）写入前副本数设置为 0；

（2）写入前关闭 refresh_interval 设置为-1，禁用刷新机制；

（3）写入过程中：采取 bulk 批量写入；

（4）写入后恢复副本数和刷新间隔；

（5）尽量使用自动生成的 id。

1.3、查询调优

（1）禁用 wildcard；

（2）禁用批量 terms（成百上千的场景）；

（3）充分利用倒排索引机制，能 keyword 类型尽量 keyword；

（4）数据量大时候，可以先基于时间敲定索引再检索；

（5）设置合理的路由机制。

1.4、其他调优

部署调优，业务调优等。

上面的提及一部分，面试者就基本对你之前的实践或者运维经验有所评估了。

# 工作原理

# es 写数据过程

  • 客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node （协调节点）。
  • coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。
  • 实际的 node 上的 primary shard 处理请求，然后将数据同步到 replica node 。
  • coordinating node 如果发现 primary node 和所有 replica node 都搞定之后，就返回响应结果给客户端。

es-write (opens new window)

# es 读数据过程

可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。

  • 客户端发送请求到任意一个 node，成为 coordinate node 。
  • coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin 随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。
  • 接收请求的 node 返回 document 给 coordinate node 。
  • coordinate node 返回 document 给客户端。

# es 搜索数据过程

es 最强大的是做全文检索，就是比如你有三条数据：

java真好玩儿啊
+java好难学啊
+j2ee特别牛
+

你根据 java 关键词来搜索，将包含 java 的 document 给搜索出来。es 就会给你返回：java 真好玩儿啊，java 好难学啊。

  • 客户端发送请求到一个 coordinate node 。
  • 协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard ，都可以。
  • query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id ）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。
  • fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

写请求是写入 primary shard，然后同步给所有的 replica shard；读请求可以从 primary shard 或 replica shard 读取，采用的是随机轮询算法。

# 写数据底层原理

es-write-detail (opens new window)

先写入内存 buffer，在 buffer 里的时候数据是搜索不到的；同时将数据写入 translog 日志文件。

如果 buffer 快满了，或者到一定时间，就会将内存 buffer 数据 refresh 到一个新的 segment file 中，但是此时数据不是直接进入 segment file 磁盘文件，而是先进入 os cache 。这个过程就是 refresh 。

每隔 1 秒钟，es 将 buffer 中的数据写入一个新的 segment file ，每秒钟会产生一个新的磁盘文件 segment file ，这个 segment file 中就存储最近 1 秒内 buffer 中写入的数据。

但是如果 buffer 里面此时没有数据，那当然不会执行 refresh 操作，如果 buffer 里面有数据，默认 1 秒钟执行一次 refresh 操作，刷入一个新的 segment file 中。

操作系统里面，磁盘文件其实都有一个东西，叫做 os cache ，即操作系统缓存，就是说数据写入磁盘文件之前，会先进入 os cache ，先进入操作系统级别的一个内存缓存中去。只要 buffer 中的数据被 refresh 操作刷入 os cache 中，这个数据就可以被搜索到了。

为什么叫 es 是准实时的？ NRT ，全称 near real-time 。默认是每隔 1 秒 refresh 一次的，所以 es 是准实时的，因为写入的数据 1 秒之后才能被看到。可以通过 es 的 restful api 或者 java api ，手动执行一次 refresh 操作，就是手动将 buffer 中的数据刷入 os cache 中，让数据立马就可以被搜索到。只要数据被输入 os cache 中，buffer 就会被清空了，因为不需要保留 buffer 了，数据在 translog 里面已经持久化到磁盘去一份了。

重复上面的步骤，新的数据不断进入 buffer 和 translog，不断将 buffer 数据写入一个又一个新的 segment file 中去，每次 refresh 完 buffer 清空，translog 保留。随着这个过程推进，translog 会变得越来越大。当 translog 达到一定长度的时候，就会触发 commit 操作。

commit 操作发生第一步，就是将 buffer 中现有数据 refresh 到 os cache 中去，清空 buffer。然后，将一个 commit point 写入磁盘文件，里面标识着这个 commit point 对应的所有 segment file ，同时强行将 os cache 中目前所有的数据都 fsync 到磁盘文件中去。最后清空 现有 translog 日志文件，重启一个 translog，此时 commit 操作完成。

这个 commit 操作叫做 flush 。默认 30 分钟自动执行一次 flush ，但如果 translog 过大，也会触发 flush 。flush 操作就对应着 commit 的全过程，我们可以通过 es api，手动执行 flush 操作，手动将 os cache 中的数据 fsync 强刷到磁盘上去。

translog 日志文件的作用是什么？你执行 commit 操作之前，数据要么是停留在 buffer 中，要么是停留在 os cache 中，无论是 buffer 还是 os cache 都是内存，一旦这台机器死了，内存中的数据就全丢了。所以需要将数据对应的操作写入一个专门的日志文件 translog 中，一旦此时机器宕机，再次重启的时候，es 会自动读取 translog 日志文件中的数据，恢复到内存 buffer 和 os cache 中去。

translog 其实也是先写入 os cache 的，默认每隔 5 秒刷一次到磁盘中去，所以默认情况下，可能有 5 秒的数据会仅仅停留在 buffer 或者 translog 文件的 os cache 中，如果此时机器挂了，会丢失 5 秒钟的数据。但是这样性能比较好，最多丢 5 秒的数据。也可以将 translog 设置成每次写操作必须是直接 fsync 到磁盘，但是性能会差很多。

实际上你在这里，如果面试官没有问你 es 丢数据的问题，你可以在这里给面试官炫一把，你说，其实 es 第一是准实时的，数据写入 1 秒后可以搜索到；可能会丢失数据的。有 5 秒的数据，停留在 buffer、translog os cache、segment file os cache 中，而不在磁盘上，此时如果宕机，会导致 5 秒的数据丢失。

总结一下，数据先写入内存 buffer，然后每隔 1s，将数据 refresh 到 os cache，到了 os cache 数据就能被搜索到（所以我们才说 es 从写入到能被搜索到，中间有 1s 的延迟）。每隔 5s，将数据写入 translog 文件（这样如果机器宕机，内存数据全没，最多会有 5s 的数据丢失），translog 大到一定程度，或者默认每隔 30mins，会触发 commit 操作，将缓冲区的数据都 flush 到 segment file 磁盘文件中。

数据写入 segment file 之后，同时就建立好了倒排索引。

# 删除/更新数据底层原理

如果是删除操作，commit 的时候会生成一个 .del 文件，里面将某个 doc 标识为 deleted 状态，那么搜索的时候根据 .del 文件就知道这个 doc 是否被删除了。

如果是更新操作，就是将原来的 doc 标识为 deleted 状态，然后新写入一条数据。

buffer 每 refresh 一次，就会产生一个 segment file ，所以默认情况下是 1 秒钟一个 segment file ，这样下来 segment file 会越来越多，此时会定期执行 merge。每次 merge 的时候，会将多个 segment file 合并成一个，同时这里会将标识为 deleted 的 doc 给物理删除掉，然后将新的 segment file 写入磁盘，这里会写一个 commit point ，标识所有新的 segment file ，然后打开 segment file 供搜索使用，同时删除旧的 segment file 。

# 底层 lucene

简单来说，lucene 就是一个 jar 包，里面包含了封装好的各种建立倒排索引的算法代码。我们用 Java 开发的时候，引入 lucene jar，然后基于 lucene 的 api 去开发就可以了。

通过 lucene，我们可以将已有的数据建立索引，lucene 会在本地磁盘上面，给我们组织索引的数据结构。

# 倒排索引

在搜索引擎中，每个文档都有一个对应的文档 ID，文档内容被表示为一系列关键词的集合。例如，文档 1 经过分词，提取了 20 个关键词，每个关键词都会记录它在文档中出现的次数和出现位置。

那么，倒排索引就是关键词到文档 ID 的映射，每个关键词都对应着一系列的文件，这些文件中都出现了关键词。

举个栗子。

有以下文档：

DocId Doc
1 谷歌地图之父跳槽 Facebook
2 谷歌地图之父加盟 Facebook
3 谷歌地图创始人拉斯离开谷歌加盟 Facebook
4 谷歌地图之父跳槽 Facebook 与 Wave 项目取消有关
5 谷歌地图之父拉斯加盟社交网站 Facebook

对文档进行分词之后，得到以下倒排索引。

WordId Word DocIds
1 谷歌 1, 2, 3, 4, 5
2 地图 1, 2, 3, 4, 5
3 之父 1, 2, 4, 5
4 跳槽 1, 4
5 Facebook 1, 2, 3, 4, 5
6 加盟 2, 3, 5
7 创始人 3
8 拉斯 3, 5
9 离开 3
10 与 4
.. .. ..

另外，实用的倒排索引还可以记录更多的信息，比如文档频率信息，表示在文档集合中有多少个文档包含某个单词。

那么，有了倒排索引，搜索引擎可以很方便地响应用户的查询。比如用户输入查询 Facebook ，搜索系统查找倒排索引，从中读出包含这个单词的文档，这些文档就是提供给用户的搜索结果。

要注意倒排索引的两个重要细节：

  • 倒排索引中的所有词项对应一个或多个文档；
  • 倒排索引中的词项根据字典顺序升序排列

上面只是一个简单的栗子，并没有严格按照字典顺序升序排列。

# elasticsearch 的倒排索引是什么

面试官：想了解你对基础概念的认知。

解答：通俗解释一下就可以。

传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置。

而倒排索引，是通过分词策略，形成了词和文章的映射关系表，这种词典+映射表即为倒排索引。有了倒排索引，就能实现 o（1）时间复杂度的效率检索文章了，极大的提高了检索效率。

img

学术的解答方式：

倒排索引，相反于一篇文章包含了哪些词，它从词出发，记载了这个词在哪些文档中出现过，由两部分组成——词典和倒排表。

加分项：倒排索引的底层实现是基于：FST（Finite State Transducer）数据结构。

lucene 从 4+版本后开始大量使用的数据结构是 FST。FST 有两个优点：

（1）空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间；

（2）查询速度快。O(len(str))的查询时间复杂度。

# 3、elasticsearch 索引数据多了怎么办，如何调优，部署

面试官：想了解大数据量的运维能力。

解答：索引数据的规划，应在前期做好规划，正所谓“设计先行，编码在后”，这样才能有效的避免突如其来的数据激增导致集群处理能力不足引发的线上客户检索或者其他业务受到影响。

如何调优，正如问题 1 所说，这里细化一下：

3.1 动态索引层面

基于模板+时间+rollover api 滚动创建索引，举例：设计阶段定义：blog 索引的模板格式为：blogindex时间戳的形式，每天递增数据。这样做的好处：不至于数据量激增导致单个索引数据量非常大，接近于上线 2 的 32 次幂-1，索引存储达到了 TB+甚至更大。

一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑+及早避免。

3.2 存储层面

冷热数据分离存储，热数据（比如最近 3 天或者一周的数据），其余为冷数据。

对于冷数据不会再写入新数据，可以考虑定期 force_merge 加 shrink 压缩操作，节省存储空间和检索效率。

3.3 部署层面

一旦之前没有规划，这里就属于应急策略。

结合 ES 自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力，注意：如果之前主节点等规划合理，不需要重启集群也能完成动态新增的。

# 4、elasticsearch 是如何实现 master 选举的

面试官：想了解 ES 集群的底层原理，不再只关注业务层面了。

解答：

前置前提：

（1）只有候选主节点（master：true）的节点才能成为主节点。

（2）最小主节点数（min_master_nodes）的目的是防止脑裂。

核对了一下代码，核心入口为 findMaster，选择主节点成功返回对应 Master，否则返回 null。选举流程大致描述如下：

第一步：确认候选主节点数达标，elasticsearch.yml 设置的值

discovery.zen.minimum_master_nodes；

第二步：比较：先判定是否具备 master 资格，具备候选主节点资格的优先返回；

若两节点都为候选主节点，则 id 小的值会主节点。注意这里的 id 为 string 类型。

题外话：获取节点 id 的方法。

1GET /_cat/nodes?v&amp;h=ip,port,heapPercent,heapMax,id,name
+
+2ip port heapPercent heapMax id name
+

# 详细描述一下 Elasticsearch 索引文档的过程

面试官：想了解 ES 的底层原理，不再只关注业务层面了。

解答：

这里的索引文档应该理解为文档写入 ES，创建索引的过程。

文档写入包含：单文档写入和批量 bulk 写入，这里只解释一下：单文档写入流程。

记住官方文档中的这个图。

img

第一步：客户写集群某节点写入数据，发送请求。（如果没有指定路由/协调节点，请求的节点扮演路由节点的角色。）

第二步：节点 1 接受到请求后，使用文档_id 来确定文档属于分片 0。请求会被转到另外的节点，假定节点 3。因此分片 0 的主分片分配到节点 3 上。

第三步：节点 3 在主分片上执行写操作，如果成功，则将请求并行转发到节点 1 和节点 2 的副本分片上，等待结果返回。所有的副本分片都报告成功，节点 3 将向协调节点（节点 1）报告成功，节点 1 向请求客户端报告写入成功。

如果面试官再问：第二步中的文档获取分片的过程？

回答：借助路由算法获取，路由算法就是根据路由和文档 id 计算目标的分片 id 的过程。

1shard = hash(_routing) % (num_of_primary_shards)
+

# 详细描述一下 Elasticsearch 搜索的过程？

面试官：想了解 ES 搜索的底层原理，不再只关注业务层面了。

解答：

搜索拆解为“query then fetch” 两个阶段。

query 阶段的目的：定位到位置，但不取。

步骤拆解如下：

（1）假设一个索引数据有 5 主+1 副本 共 10 分片，一次请求会命中（主或者副本分片中）的一个。

（2）每个分片在本地进行查询，结果返回到本地有序的优先队列中。

（3）第 2）步骤的结果发送到协调节点，协调节点产生一个全局的排序列表。

fetch 阶段的目的：取数据。

路由节点获取所有文档，返回给客户端。

# Elasticsearch 在部署时，对 Linux 的设置有哪些优化方法

面试官：想了解对 ES 集群的运维能力。

解答：

（1）关闭缓存 swap;

（2）堆内存设置为：Min（节点内存/2, 32GB）;

（3）设置最大文件句柄数；

（4）线程池+队列大小根据业务需要做调整；

（5）磁盘存储 raid 方式——存储有条件使用 RAID10，增加单节点性能以及避免单节点存储故障。

# lucence 内部结构是什么？

面试官：想了解你的知识面的广度和深度。

解答：

img

Lucene 是有索引和搜索的两个过程，包含索引创建，索引，搜索三个要点。可以基于这个脉络展开一些。

# Elasticsearch 是如何实现 Master 选举的？

（1）Elasticsearch 的选主是 ZenDiscovery 模块负责的，主要包含 Ping（节点之间通过这个 RPC 来发现彼此）和 Unicast（单播模块包含一个主机列表以控制哪些节点需要 ping 通）这两部分；

（2）对所有可以成为 master 的节点（node.master: true）根据 nodeId 字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第 0 位）节点，暂且认为它是 master 节点。

（3）如果对某个节点的投票数达到一定的值（可以成为 master 节点数 n/2+1）并且该节点自己也选举自己，那这个节点就是 master。否则重新选举一直到满足上述条件。

（4）补充：master 节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data 节点可以关闭 http 功能*。

# 10、Elasticsearch 中的节点（比如共 20 个），其中的 10 个

选了一个 master，另外 10 个选了另一个 master，怎么办？

（1）当集群 master 候选数量不小于 3 个时，可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes）超过所有候选节点一半以上来解决脑裂问题；

（3）当候选数量为两个时，只能修改为唯一的一个 master 候选，其他作为 data 节点，避免脑裂问题。

# 客户端在和集群连接时，如何选择特定的节点执行请求的？

TransportClient 利用 transport 模块远程连接一个 elasticsearch 集群。它并不加入到集群中，只是简单的获得一个或者多个初始化的 transport 地址，并以 轮询 的方式与这些地址进行通信。

# 详细描述一下 Elasticsearch 索引文档的过程。

协调节点默认使用文档 ID 参与计算（也支持通过 routing），以便为路由提供合适的分片。

shard = hash(document_id) % (num_of_primary_shards)
+

（1）当分片所在的节点接收到来自协调节点的请求后，会将请求写入到 MemoryBuffer，然后定时（默认是每隔 1 秒）写入到 Filesystem Cache，这个从 MomeryBuffer 到 Filesystem Cache 的过程就叫做 refresh；

（2）当然在某些情况下，存在 Momery Buffer 和 Filesystem Cache 的数据可能会丢失，ES 是通过 translog 的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到 translog 中 ，当 Filesystem cache 中的数据写入到磁盘中时，才会清除掉，这个过程叫做 flush；

（3）在 flush 过程中，内存中的缓冲将被清除，内容被写入一个新段，段的 fsync 将创建一个新的提交点，并将内容刷新到磁盘，旧的 translog 将被删除并开始一个新的 translog。

（4）flush 触发的时机是定时触发（默认 30 分钟）或者 translog 变得太大（默认为 512M）时；

img

补充：关于 Lucene 的 Segement：

（1）Lucene 索引是由多个段组成，段本身是一个功能齐全的倒排索引。

（2）段是不可变的，允许 Lucene 将新的文档增量地添加到索引中，而不用从头重建索引。

（3）对于每一个搜索请求而言，索引中的所有段都会被搜索，并且每个段会消耗 CPU 的时钟周、文件句柄和内存。这意味着段的数量越多，搜索性能会越低。

（4）为了解决这个问题，Elasticsearch 会合并小段到一个较大的段，提交新的合并段到磁盘，并删除那些旧的小段。

# 详细描述一下 Elasticsearch 更新和删除文档的过程。

（1）删除和更新也都是写操作，但是 Elasticsearch 中的文档是不可变的，因此不能被删除或者改动以展示其变更；

（2）磁盘上的每个段都有一个相应的.del 文件。当删除请求发送后，文档并没有真的被删除，而是在.del 文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del 文件中被标记为删除的文档将不会被写入新段。

（3）在新的文档被创建时，Elasticsearch 会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del 文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。

# 详细描述一下 Elasticsearch 搜索的过程。

（1）搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch；

（2）在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。

PS：在搜索的时候是会查询 Filesystem Cache 的，但是有部分数据还在 MemoryBuffer，所以搜索是近实时的。

（3）每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。

（4）接下来就是 取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并 丰 富 文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。

（5）补充：Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch 增加了一个预查询的处理，询问 Term 和 Document frequency，这个评分更准确，但是性能会变差。*

img

# 在 Elasticsearch 中，是怎么根据一个词找到对应的倒排索引的？

（1）Lucene 的索引过程，就是按照全文检索的基本过程，将倒排表写成此文件格式的过程。

（2）Lucene 的搜索过程，就是按照此文件格式将索引进去的信息读出来，然后计算每篇文档打分(score)的过程。

# Elasticsearch 在部署时，对 Linux 的设置有哪些优化方法？

（1）64 GB 内存的机器是非常理想的， 但是 32 GB 和 16 GB 机器也是很常见的。少于 8 GB 会适得其反。

（2）如果你要在更快的 CPUs 和更多的核心之间选择，选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。

（3）如果你负担得起 SSD，它将远远超出任何旋转介质。 基于 SSD 的节点，查询和索引性能都有提升。如果你负担得起，SSD 是一个好的选择。

（4）即使数据中心们近在咫尺，也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理距离。

（5）请确保运行你应用程序的 JVM 和服务器的 JVM 是完全一样的。 在 Elasticsearch 的几个地方，使用 Java 的本地序列化。

（6）通过设置 gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time 可以在集群重启的时候避免过多的分片交换，这可能会让数据恢复从数个小时缩短为几秒钟。

（7）Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。最好使用单播代替组播。

（8）不要随意修改垃圾回收器（CMS）和各个线程池的大小。

（9）把你的内存的（少于）一半给 Lucene（但不要超过 32 GB！），通过 ES_HEAP_SIZE 环境变量设置。

（10）内存交换到磁盘对服务器性能来说是致命的。如果内存交换到磁盘上，一个 100 微秒的操作可能变成 10 毫秒。 再想想那么多 10 微秒的操作时延累加起来。 不难看出 swapping 对于性能是多么可怕。

（11）Lucene 使用了大 量 的文件。同时，Elasticsearch 在节点和 HTTP 客户端之间进行通信也使用了大量的套接字。 所有这一切都需要足够的文件描述符。你应该增加你的文件描述符，设置一个很大的值，如 64,000。

补充：索引阶段性能提升方法

（1）使用批量请求并调整其大小：每次批量数据 5–15 MB 大是个不错的起始点。

（2）存储：使用 SSD

（3）段和合并：Elasticsearch 默认值是 20 MB/s，对机械磁盘应该是个不错的设置。如果你用的是 SSD，可以考虑提高到 100–200 MB/s。如果你在做批量导入，完全不在意搜索，你可以彻底关掉合并限流。另外还可以增加 index.translog.flush_threshold_size 设置，从默认的 512 MB 到更大一些的值，比如 1 GB，这可以在一次清空触发的时候在事务日志里积累出更大的段。

（4）如果你的搜索结果不需要近实时的准确度，考虑把每个索引的 index.refresh_interval 改到 30s。

（5）如果你在做大批量导入，考虑通过设置 index.number_of_replicas: 0 关闭副本。

# 对于 GC 方面，在使用 Elasticsearch 时要注意什么？

（1）倒排词典的索引需要常驻内存，无法 GC，需要监控 data node 上 segmentmemory 增长趋势。

（2）各类缓存，field cache, filter cache, indexing cache, bulk queue 等等，要设置合理的大小，并且要应该根据最坏的情况来看 heap 是否够用，也就是各类缓存全部占满的时候，还有 heap 空间可以分配给其他任务吗？避免采用 clear cache 等“自欺欺人”的方式来释放内存。

（3）避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用 scan & scroll api 来实现。

（4）cluster stats 驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过 tribe node 连接。

（5）想知道 heap 够不够，必须结合实际应用场景，并对集群的 heap 使用情况做持续的监控。

（6）根据监控数据理解内存需求，合理配置各类 circuit breaker，将内存溢出风险降低到最低

# 18、Elasticsearch 对于大数据量（上亿量级）的聚合如何实现？

Elasticsearch 提供的首个近似聚合是 cardinality 度量。它提供一个字段的基数，即该字段的 distinct 或者 unique 值的数目。它是基于 HLL 算法的。HLL 会先对我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关。

# 19、在并发情况下，Elasticsearch 如果保证读写一致？

（1）可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；

（2）另外对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。

（3）对于读操作，可以设置 replication 为 sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜索请求参数_preference 为 primary 来查询主分片，确保文档是最新版本。

# 20、如何监控 Elasticsearch 集群状态？

Marvel 让你可以很简单的通过 Kibana 监控 Elasticsearch。你可以实时查看你的集群健康状态和性能，也可以分析过去的集群、索引和节点指标。

# 21、介绍下你们电商搜索的整体技术架构。

img

# 介绍一下你们的个性化搜索方案？

基于 word2vec 和 Elasticsearch 实现个性化搜索

（1）基于 word2vec、Elasticsearch 和自定义的脚本插件，我们就实现了一个个性化的搜索服务，相对于原有的实现，新版的点击率和转化率都有大幅的提升；

（2）基于 word2vec 的商品向量还有一个可用之处，就是可以用来实现相似商品的推荐；

（3）使用 word2vec 来实现个性化搜索或个性化推荐是有一定局限性的，因为它只能处理用户点击历史这样的时序数据，而无法全面的去考虑用户偏好，这个还是有很大的改进和提升的空间；

# 是否了解字典树？

常用字典数据结构如下所示：

img

Trie 的核心思想是空间换时间，利用字符串的公共前缀来降低查询时间的开销以达到提高效率的目的。它有 3 个基本性质：

1）根节点不包含字符，除根节点外每一个节点都只包含一个字符。

2）从根节点到某一节点，路径上经过的字符连接起来，为该节点对应的字符串。

3）每个节点的所有子节点包含的字符都不相同。

img

（1）可以看到，trie 树每一层的节点数是 26^i 级别的。所以为了节省空间，我们还可以用动态链表，或者用数组来模拟动态。而空间的花费，不会超过单词数 × 单词长度。

（2）实现：对每个结点开一个字母集大小的数组，每个结点挂一个链表，使用左儿子右兄弟表示法记录这棵树；

（3）对于中文的字典树，每个节点的子节点用一个哈希表存储，这样就不用浪费太大的空间，而且查询速度上可以保留哈希的复杂度 O(1)。

# 拼写纠错是如何实现的？

（1）拼写纠错是基于编辑距离来实现；编辑距离是一种标准的方法，它用来表示经过插入、删除和替换操作从一个字符串转换到另外一个字符串的最小操作步数；

（2）编辑距离的计算过程：比如要计算 batyu 和 beauty 的编辑距离，先创建一个 7×8 的表（batyu 长度为 5，coffee 长度为 6，各加 2），接着，在如下位置填入黑色数字。其他格的计算过程是取以下三个值的最小值：

如果最上方的字符等于最左方的字符，则为左上方的数字。否则为左上方的数字+1。（对于 3,3 来说为 0）

左方数字+1（对于 3,3 格来说为 2）

上方数字+1（对于 3,3 格来说为 2）

最终取右下角的值即为编辑距离的值 3。

img

对于拼写纠错，我们考虑构造一个度量空间（Metric Space），该空间内任何关系满足以下三条基本条件：

d(x,y) = 0 -- 假如 x 与 y 的距离为 0，则 x=y

d(x,y) = d(y,x) -- x 到 y 的距离等同于 y 到 x 的距离

d(x,y) + d(y,z) >= d(x,z) -- 三角不等式

（1）根据三角不等式，则满足与 query 距离在 n 范围内的另一个字符转 B，其与 A 的距离最大为 d+n，最小为 d-n。

（2）BK 树的构造就过程如下：每个节点有任意个子节点，每条边有个值表示编辑距离。所有子节点到父节点的边上标注 n 表示编辑距离恰好为 n。比如，我们有棵树父节点是”book”和两个子节点”cake”和”books”，”book”到”books”的边标号 1，”book”到”cake”的边上标号 4。从字典里构造好树后，无论何时你想插入新单词时，计算该单词与根节点的编辑距离，并且查找数值为 d(neweord, root)的边。递归得与各子节点进行比较，直到没有子节点，你就可以创建新的子节点并将新单词保存在那。比如，插入”boo”到刚才上述例子的树中，我们先检查根节点，查找 d(“book”, “boo”) = 1 的边，然后检查标号为 1 的边的子节点，得到单词”books”。我们再计算距离 d(“books”, “boo”)=2，则将新单词插在”books”之后，边标号为 2。

（3）查询相似词如下：计算单词与根节点的编辑距离 d，然后递归查找每个子节点标号为 d-n 到 d+n（包含）的边。假如被检查的节点与搜索单词的距离 d 小于 n，则返回该节点并继续查询。比如输入 cape 且最大容忍距离为 1，则先计算和根的编辑距离 d(“book”, “cape”)=4，然后接着找和根节点之间编辑距离为 3 到 5 的，这个就找到了 cake 这个节点，计算 d(“cake”, “cape”)=1，满足条件所以返回 cake，然后再找和 cake 节点编辑距离是 0 到 2 的，分别找到 cape 和 cart 节点，这样就得到 cape 这个满足条件的结果。

img

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#面试
上次更新: 2023/06/29, 22:27:04
Cassandra
Elasticsearch 快速入门

+ ← + Elasticsearch 快速入门→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/0e1012/index.html b/pages/0e1012/index.html new file mode 100644 index 00000000..b9fd3ff4 --- /dev/null +++ b/pages/0e1012/index.html @@ -0,0 +1,66 @@ + + + + + + Nosql技术选型 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-02-09
目录

Nosql技术选型

# Nosql 技术选型

img

# 一、Nosql 简介

传统的关系型数据库存在以下缺点：

  • 大数据场景下 I/O 较高 - 因为数据是按行存储，即使只针对其中某一列进行运算，关系型数据库也会将整行数据从存储设备中读入内存，导致 I/O 较高。
  • 存储的是行记录，无法存储数据结构。
  • 表结构 schema 扩展不方便 - 如要需要修改表结构，需要执行执行 DDL(data definition language)，语句修改，修改期间会导致锁表，部分服务不可用。
  • 全文搜索功能较弱 - 关系型数据库下只能够进行子字符串的匹配查询，当表的数据逐渐变大的时候，LIKE 查询的匹配会非常慢，即使在有索引的情况下。况且关系型数据库也不应该对文本字段进行索引。
  • 存储和处理复杂关系型数据功能较弱 - 许多应用程序需要了解和导航高度连接数据之间的关系，才能启用社交应用程序、推荐引擎、欺诈检测、知识图谱、生命科学和 IT/网络等用例。然而传统的关系数据库并不善于处理数据点之间的关系。它们的表格数据模型和严格的模式使它们很难添加新的或不同种类的关联信息。

随着大数据时代的到来，越来越多的网站、应用系统需要支撑海量数据存储，高并发请求、高可用、高可扩展性等特性要求。传统的关系型数据库在应付这些调整已经显得力不从心，暴露了许多能以克服的问题。由此，各种各样的 NoSQL（Not Only SQL）数据库作为传统关系型数据的一个有力补充得到迅猛发展。

nosql-history

NoSQL，泛指非关系型的数据库，可以理解为 SQL 的一个有力补充。

在 NoSQL 许多方面性能大大优于非关系型数据库的同时，往往也伴随一些特性的缺失，比较常见的，是事务库事务功能的缺失。 数据库事务正确执行的四个基本要素：ACID 如下：

名称 描述
A Atomicity (原子性) 一个事务中的所有操作，要么全部完成，要么全部不完成，不会在中间某个环节结束。 事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样。
C Consistency 一致性 在事务开始之前和事务结束以后，数据的数据的一致性约束没有被破坏。
I Isolation 隔离性 数据库允许多个并发事务同时对数据进行读写和修改的能力。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
D Durability 持久性 事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

下面介绍 5 大类 NoSQL 数据针对传统关系型数据库的缺点提供的解决方案：

# 二、列式数据库

列式数据库是以列相关存储架构进行数据存储的数据库，主要适合于批量数据处理和即时查询。

相对应的是行式数据库，数据以行相关的存储体系架构进行空间分配，主要适合于小批量的数据处理，常用于联机事务型数据处理。

基于列式数据库的列列存储特性，可以解决某些特定场景下关系型数据库 I/O 较高的问题。

# 列式数据库原理

传统关系型数据库是按照行来存储数据库，称为“行式数据库”，而列式数据库是按照列来存储数据。

将表放入存储系统中有两种方法，而我们绝大部分是采用行存储的。 行存储法是将各行放入连续的物理位置，这很像传统的记录和文件系统。 列存储法是将数据按照列存储到数据库中，与行存储类似，下图是两种存储方法的图形化解释：

按行存储和按列存储模式

# 列式数据库产品

  • HBase

    HBase

    HBase 是一个开源的非关系型分布式数据库（NoSQL），它参考了谷歌的 BigTable 建模，实现的编程语言为 Java。它是 Apache 软件基金会的 Hadoop 项目的一部分，运行于 HDFS 文件系统之上，为 Hadoop 提供类似于 BigTable 规模的服务。因此，它可以容错地存储海量稀疏的数据。

  • BigTable

    img

    BigTable 是一种压缩的、高性能的、高可扩展性的，基于 Google 文件系统（Google File System，GFS）的数据存储系统，用于存储大规模结构化数据，适用于云端计算。

# 列式数据库特性

优点如下：

  • 高效的储存空间利用率

列式数据库由于其针对不同列的数据特征而发明的不同算法，使其往往有比行式数据库高的多的压缩率，普通的行式数据库一般压缩率在 3：1 到 5：1 左右，而列式数据库的压缩率一般在 8：1 到 30：1 左右。 比较常见的，通过字典表压缩数据： 下面中才是那张表本来的样子。经过字典表进行数据压缩后，表中的字符串才都变成数字了。正因为每个字符串在字典表里只出现一次了，所以达到了压缩的目的(有点像规范化和非规范化 Normalize 和 Denomalize)

通过字典表压缩数据

  • 查询效率高

读取多条数据的同一列效率高，因为这些列都是存储在一起的，一次磁盘操作可以数据的指定列全部读取到内存中。 下图通过一条查询的执行过程说明列式存储(以及数据压缩)的优点

img

执行步骤如下：
+i. 去字典表里找到字符串对应数字(只进行一次字符串比较)。
+ii. 用数字去列表里匹配，匹配上的位置设为1。
+iii. 把不同列的匹配结果进行位运算得到符合所有条件的记录下标。
+iv. 使用这个下标组装出最终的结果集。
+复制代码
+
  • 适合做聚合操作
  • 适合大量的数据而不是小数据

缺点如下：

  • 不适合扫描小量数据
  • 不适合随机的更新
  • 不适合做含有删除和更新的实时操作
  • 单行的数据是 ACID 的，多行的事务时，不支持事务的正常回滚，支持 I(Isolation)隔离性(事务串行提交)，D(Durability)持久性，不能保证 A(Atomicity)原子性， C(Consistency)一致性

# 列式数据库使用场景

以 HBase 为例说明：

  • 大数据量 （100s TB 级数据） 且有快速随机访问的需求。增长量无法预估的应用，需要进行优雅的数据扩展的 HBase 支持在线扩展，即使在一段时间内数据量呈井喷式增长，也可以通过 HBase 横向扩展来满足功能。
  • 写密集型应用，每天写入量巨大，而相对读数量较小的应用 比如 IM 的历史消息，游戏的日志等等
  • 不需要复杂查询条件来查询数据的应用 HBase 只支持基于 rowkey 的查询，对于 HBase 来说，单条记录或者小范围的查询是可以接受的，大范围的查询由于分布式的原因，可能在性能上有点影响，HBase 不适用于有 join，多级索引，表关系复杂的数据模型。
  • 对性能和可靠性要求非常高的应用，由于 HBase 本身没有单点故障，可用性非常高。
  • 存储结构化和半结构化的数据。

# 三、K-V 数据库

K-V 数据库指的是使用键值(key-value)存储的数据库，其数据按照键值对的形式进行组织、索引和存储。

KV 存储非常适合存储不涉及过多数据关系业务关系的数据，同时能有效减少读写磁盘的次数，比 SQL 数据库存储拥有更好的读写性能，能够解决关系型数据库无法存储数据结构的问题。

# K-V 数据库产品

  • Redis

    img

    Redis 是一个使用 ANSI C 编写的开源、支持网络、基于内存、可选持久性的键值对存储数据库。从 2015 年 6 月开始，Redis 的开发由 Redis Labs 赞助，而 2013 年 5 月至 2015 年 6 月期间，其开发由 Pivotal 赞助。在 2013 年 5 月之前，其开发由 VMware 赞助。根据月度排行网站 DB-Engines.com 的数据显示，Redis 是最流行的键值对存储数据库。

  • Cassandra

    img

    Apache Cassandra（社区内一般简称为 C*）是一套开源分布式 NoSQL 数据库系统。它最初由 Facebook 开发，用于储存收件箱等简单格式数据，集 Google BigTable 的数据模型与 Amazon Dynamo 的完全分布式架构于一身。Facebook 于 2008 将 Cassandra 开源，此后，由于 Cassandra 良好的可扩展性和性能，被 Apple, Comcast,Instagram, Spotify, eBay, Rackspace, Netflix 等知名网站所采用，成为了一种流行的分布式结构化数据存储方案。

  • LevelDB

    img

    LevelDB 是一个由 Google 公司所研发的键／值对（Key/Value Pair）嵌入式数据库管理系统编程库， 以开源的 BSD 许可证发布。

# K-V 数据库特性

以 Redis 为例：

优点如下：

  • 性能极高 - Redis 能支持超过 10W 的 TPS。
  • 丰富的数据类型 - Redis 支持包括 String，Hash，List，Set，Sorted Set，Bitmap 和 hyperloglog。
  • 丰富的特性 - Redis 还支持 publish/subscribe、通知、key 过期等等特性。

缺点如下： 针对 ACID，Redis 事务不能支持原子性和持久性(A 和 D)，只支持隔离性和一致性(I 和 C) 特别说明一下，这里所说的无法保证原子性，是针对 Redis 的事务操作，因为事务是不支持回滚（roll back），而因为 Redis 的单线程模型，Redis 的普通操作是原子性的。

大部分业务不需要严格遵循 ACID 原则，例如游戏实时排行榜，粉丝关注等场景，即使部分数据持久化失败，其实业务影响也非常小。因此在设计方案时，需要根据业务特征和要求来做选择

# K-V 数据库使用场景

  • 适用场景 - 储存用户信息(比如会话)、配置文件、参数、购物车等等。这些信息一般都和 ID（键）挂钩。

  • 不适用场景

    • 需要通过值来查询，而不是键来查询。Key-Value 数据库中根本没有通过值查询的途径。
    • 需要储存数据之间的关系。在 Key-Value 数据库中不能通过两个或以上的键来关联数据
    • 需要事务的支持。在 Key-Value 数据库中故障产生时不可以进行回滚。

# 四、文档数据库

文档数据库（也称为文档型数据库）是旨在将半结构化数据存储为文档的一种数据库，它可以解决关系型数据库表结构 schema 扩展不方便的问题。文档数据库通常以 JSON 或 XML 格式存储数据。

由于文档数据库的 no-schema 特性，可以存储和读取任意数据。由于使用的数据格式是 JSON 或者 XML，无需在使用前定义字段，读取一个 JSON 中不存在的字段也不会导致 SQL 那样的语法错误。

# 文档数据库产品

  • MongoDB

    img

    MongoDB是一种面向文档的数据库管理系统，由 C++ 撰写而成，以此来解决应用程序开发社区中的大量现实问题。2007 年 10 月，MongoDB 由 10gen 团队所发展。2009 年 2 月首度推出。

  • CouchDB

    img

    Apache CouchDB 是一个开源数据库，专注于易用性和成为"完全拥抱 web 的数据库"。它是一个使用 JSON 作为存储格式，JavaScript 作为查询语言，MapReduce 和 HTTP 作为 API 的 NoSQL 数据库。其中一个显著的功能就是多主复制。CouchDB 的第一个版本发布在 2005 年，在 2008 年成为了 Apache 的项目。

# 文档数据库特性

以 MongoDB 为例进行说明

优点如下：

  • 容易存储复杂数据结构 - JSON 是一种强大的描述语言，能够描述复杂的数据结构。
  • 容易变更数据结构 - 无需像关系型数据库一样先执行 DDL 语句修改表结构，程序代码直接读写即可。
  • 容易兼容历史数据 - 对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时代码兼容处理即可。

缺点如下：

  • 部分支持事务
    • Atomicity(原子性) 仅支持单行/文档级原子性，不支持多行、多文档、多语句原子性。
    • Isolation(隔离性) 隔离级别仅支持已提交读（Read committed）级别，可能导致不可重复读，幻读的问题。
  • 不支持复杂查询 - 例如 join 查询，如果需要 join 查询，需要多次操作数据库。

MongonDB 还是支持多文档事务的 Consistency(一致性)和 Durability(持久性)

虽然官方宣布 MongoDB 将在 4.0 版本中正式推出多文档 ACID 事务支持，最后落地情况还有待见证。

# 文档数据库使用场景

适用场景：

  • 大数据量，且未来数据增长很快
  • 表结构不明确，且字段在不断增加，例如内容管理系统，信息管理系统

不适用场景：

  • 支持事务 - 在不同的文档上需要添加事务。Document-Oriented 数据库并不支持文档间的事务
  • 支持复杂查询 - 多个文档直接需要复杂查询，例如 join

# 五、全文搜索引擎

传统关系型数据库主要通过索引来达到快速查询的目的，在全文搜索的业务下，索引也无能为力，主要体现在：

  • 全文搜索的条件可以随意排列组合，如果通过索引来满足，则索引的数量非常多
  • 全文搜索的模糊匹配方式，索引无法满足，只能用 LIKE 查询，而 LIKE 查询是整表扫描，效率非常低

而全文搜索引擎的出现，正是解决关系型数据库全文搜索功能较弱的问题。

# 搜索引擎原理

全文搜索引擎的技术原理称为 倒排索引（inverted index），是一种索引方法，其基本原理是建立单词到文档的索引。与之相对是，是“正排索引”，其基本原理是建立文档到单词的索引。

现在有如下文档集合：

img

正排索引得到索引如下：

img

可见，正排索引适用于根据文档名称查询文档内容

简单的倒排索引如下：

img

带有单词频率信息的倒排索引如下：

img

可见，倒排索引适用于根据关键词来查询文档内容

# 搜索引擎产品

  • Elasticsearch

    img

    Elasticsearch 是一个基于 Lucene 的搜索引擎。它提供了一个分布式，多租户 -能够全文搜索与发动机 HTTP Web 界面和无架构 JSON 文件。Elasticsearch 是用 Java 开发的，并根据 Apache License 的条款作为开源发布。根据 DB-Engines 排名，Elasticsearch 是最受欢迎的企业搜索引擎，后面是基于 Lucene 的 Apache Solr。

  • Solr

    img

    Solr 是 Apache Lucene 项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如 Word、PDF）的处理。Solr 是高度可扩展的，并提供了分布式搜索和索引复制

# 搜索引擎特性

以 Elasticsearch 为例： 优点如下：

  • 查询效率高 - 对海量数据进行近实时的处理
  • 可扩展性 - 基于集群环境可以方便横向扩展，可以承载 PB 级数据
  • 高可用 - Elasticsearch 集群弹性-他们将发现新的或失败的节点，重组和重新平衡数据，确保数据是安全的和可访问的

缺点如下：

  • 部分支持事务 - 单一文档的数据是 ACID 的，包含多个文档的事务时不支持事务的正常回滚，支持 I(Isolation)隔离性（基于乐观锁机制的），D(Durability)持久性，不支持 A(Atomicity)原子性，C(Consistency)一致性
  • 对类似数据库中通过外键的复杂的多表关联操作支持较弱。
  • 读写有一定延时，写入的数据，最快 1s 中能被检索到
  • 更新性能较低，底层实现是先删数据，再插入新数据
  • 内存占用大，因为 Lucene 将索引部分加载到内存中

# 搜索引擎场景

适用场景如下：

  • 搜索引擎和数据分析引擎 - 全文检索，结构化检索，数据分析
  • 对海量数据进行近实时的处理 - 可以将海量数据分散到多台服务器上去存储和检索

不适用场景如下：

  • 数据需要频繁更新
  • 需要复杂关联查询

# 六、图数据库

img

图形数据库应用图论存储实体之间的关系信息。最常见例子就是社会网络中人与人之间的关系。关系型数据库用于存储“关系型”数据的效果并不好，其查询复杂、缓慢、超出预期，而图形数据库的独特设计恰恰弥补了这个缺陷，解决关系型数据库存储和处理复杂关系型数据功能较弱的问题。

# 图数据库产品

  • Neo4j

    img

    Neo4j 是由 Neo4j，Inc。开发的图形数据库管理系统。由其开发人员描述为具有原生图存储和处理的符合 ACID 的事务数据库，根据 DB-Engines 排名， Neo4j 是最流行的图形数据库。

  • ArangoDB

    img

    ArangoDB 是由 triAGENS GmbH 开发的原生多模型数据库系统。数据库系统支持三个重要的数据模型（键/值，文档，图形），其中包含一个数据库核心和统一查询语言 AQL（ArangoDB 查询语言）。查询语言是声明性的，允许在单个查询中组合不同的数据访问模式。ArangoDB 是一个 NoSQL 数据库系统，但 AQL 在很多方面与 SQL 类似。

  • Titan

    img

    Titan 是一个可扩展的图形数据库，针对存储和查询包含分布在多机群集中的数百亿个顶点和边缘的图形进行了优化。Titan 是一个事务性数据库，可以支持数千个并发用户实时执行复杂的图形遍历。

# 图数据库特性

以 Neo4j 为例：

Neo4j 使用数据结构中图（graph）的概念来进行建模。 Neo4j 中两个最基本的概念是节点和边。节点表示实体，边则表示实体之间的关系。节点和边都可以有自己的属性。不同实体通过各种不同的关系关联起来，形成复杂的对象图。

针对关系数据，2 种 2 数据库的存储结构不同：

2种存储结构

Neo4j 中，存储节点时使用了”index-free adjacency”，即每个节点都有指向其邻居节点的指针，可以让我们在 O(1)的时间内找到邻居节点。另外，按照官方的说法，在 Neo4j 中边是最重要的,是”first-class entities”，所以单独存储，这有利于在图遍历的时候提高速度，也可以很方便地以任何方向进行遍历

img

如下优点：

  • 高性能 - 图的遍历是图数据结构所具有的独特算法，即从一个节点开始，根据其连接的关系，可以快速和方便地找出它的邻近节点。这种查找数据的方法并不受数据量的大小所影响，因为邻近查询始终查找的是有限的局部数据，不会对整个数据库进行搜索
  • 设计的灵活性 - 数据结构的自然伸展特性及其非结构化的数据格式，让图数据库设计可以具有很大的伸缩性和灵活性。因为随着需求的变化而增加的节点、关系及其属性并不会影响到原来数据的正常使用
  • 开发的敏捷性 - 直观明了的数据模型，从需求的讨论开始，到程序开发和实现，以及最终保存在数据库中的样子，它的模样似乎没有什么变化，甚至可以说本来就是一模一样的
  • 完全支持 ACID - 不像别的 NoSQL 数据库 Neo4j 还具有完全事务管理特性，完全支持 ACID 事务管理

缺点如下：

  • 存在支持节点，关系和属性的数量的限制。
  • 不支持拆分。

# 图数据库场景

适用场景如下：

  • 关系性强的数据中，如社交网络
  • 推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定

不适用场景如下：

  • 记录大量基于事件的数据（例如日志条目或传感器数据）
  • 对大规模分布式数据进行处理
  • 保存在关系型数据库中的结构化数据
  • 二进制数据存储

# 七、总结

关系型数据库和 NoSQL 数据库的选型，往往需要考虑几个指标：

  • 数据量
  • 并发量
  • 实时性
  • 一致性要求
  • 读写分布和类型
  • 安全性
  • 运维成本

常见软件系统数据库选型参考如下：

  • 中后台管理型系统 - 如运营系统，数据量少，并发量小，首选关系型数据库。
  • 大流量系统 - 如电商单品页，后台考虑选关系型数据库，前台考虑选内存型数据库。
  • 日志型系统 - 原始数据考虑选列式数据库，日志搜索考虑选搜索引擎。
  • 搜索型系统 - 例如站内搜索，非通用搜索，如商品搜索，后台考虑选关系型数据库，前台考虑选搜索引擎。
  • 事务型系统 - 如库存，交易，记账，考虑选关系型数据库+K-V 数据库（作为缓存）+分布式事务。
  • 离线计算 - 如大量数据分析，考虑选列式数据库或关系型数据。
  • 实时计算 - 如实时监控，可以考虑选内存型数据库或者列式数据库。

设计实践中，要基于需求、业务驱动架构，无论选用 RDB/NoSQL/DRDB,一定是以需求为导向，最终数据存储方案必然是各种权衡的综合性设计

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#综合#Nosql
上次更新: 2023/06/29, 22:27:04
数据结构与数据库索引

数据结构与数据库索引→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/0fb506/index.html b/pages/0fb506/index.html new file mode 100644 index 00000000..5407f002 --- /dev/null +++ b/pages/0fb506/index.html @@ -0,0 +1,229 @@ + + + + + + Elasticsearch 简介 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-02-22
目录

Elasticsearch 简介

# Elasticsearch 简介

Elasticsearch 是一个基于 Lucene 的搜索和数据分析工具，它提供了一个分布式服务。Elasticsearch 是遵从 Apache 开源条款的一款开源产品，是当前主流的企业级搜索引擎。

它用于全文搜索、结构化搜索、分析以及将这三者混合使用：

  • 维基百科使用 Elasticsearch 提供全文搜索并高亮关键字，以及**输入实时搜索(search-as-you-type)和搜索纠错(did-you-mean)**等搜索建议功能。
  • 英国卫报使用 Elasticsearch 结合用户日志和社交网络数据提供给他们的编辑以实时的反馈，以便及时了解公众对新发表的文章的回应。
  • StackOverflow 结合全文搜索与地理位置查询，以及more-like-this功能来找到相关的问题和答案。
  • Github 使用 Elasticsearch 检索 1300 亿行的代码。

# Elasticsearch 特点

  • 分布式的实时文件存储，每个字段都被索引并可被搜索；
  • 分布式的实时分析搜索引擎；
  • 可弹性扩展到上百台服务器规模，处理 PB 级结构化或非结构化数据；
  • 开箱即用（安装即可使用），它提供了许多合理的缺省值，并对初学者隐藏了复杂的搜索引擎理论。只需很少的学习既可在生产环境中使用。

# Elasticsearch 发展历史

  • 2010 年 2 月 8 日，Elasticsearch 第一个公开版本发布。

  • 2010 年 5 月 14 日，发布第一个具有里程碑意义的初始版本 0.7.0 ，具有如下特征：

  • Zen Discovery 自动发现模块；

    • 支持 Groovy Client；

  • 简单的插件管理机制；

    • 更好地支持 icu 分词器；

  • 更多的管理 api。

  • 2013 年初，GitHub 抛弃了 Solr，采取 ElasticSearch 来做其 PB 级的搜索。

  • 2014 年 2 月 14 日，发布 1.0.0 版本，增加如下重要特性：

  • 支持 Snapshot/Restore API 备份恢复 API；

    • 支持聚合分析 Aggregations；

  • 支持 cat api；

    • 支持断路器；

  • 引入 Doc values。

  • 2015 年 10 月 28 日，发布 2.0.0 版本，有如下重要特性：

  • 增加了 Pipleline Aggregations；

    • query/filter 查询合并，都合并到 query 中，根据不同的上下文执行不同的查询；

  • 压缩存储可配置；

    • Rivers 模块被移除；

  • Multicast 组播发现被移除，成为一个插件，生产环境必须配置单播地址。

  • 2016 年 10 月 26 日，发布 5.0.0 版本，有如下重大特性变化：

  • Lucene 6.x 的支持，磁盘空间少一半；索引时间少一半；查询性能提升 25%；支持 IPV6；

    • Internal Engine 级别移除了用于避免同一文档并发更新的竞争锁，带来 15%-20% 的性能提升；

  • Shrink API，它可将分片数进行收缩成它的因数，如之前你是 15 个分片，你可以收缩成 5 个或者 3 个又或者 1 个，那么我们就可以想象成这样一种场景，在写入压力非常大的收集阶段，设置足够多的索引，充分利用 shard 的并行写能力，索引写完之后收缩成更少的 shard，提高查询性能；

    • 提供了第一个 Java 原生的 REST 客户端 SDK；

  • IngestNode，之前如果需要对数据进行加工，都是在索引之前进行处理，比如 logstash 可以对日志进行结构化和转换，现在直接在 es 就可以处理了；

    • 提供了 Painless 脚本，代替 Groovy 脚本；
    • 移除 site plugins，就是说 head、bigdesk 都不能直接装 es 里面了，不过可以部署独立站点（反正都是静态文件）或开发 kibana 插件；
    • 新增 Sliced Scroll 类型，现在 Scroll 接口可以并发来进行数据遍历了。每个 Scroll 请求，可以分成多个 Slice 请求，可以理解为切片，各 Slice 独立并行，利用 Scroll 重建或者遍历要快很多倍；
    • 新增了 Profile API；
    • 新增了 Rollover API；
    • 新增 Reindex；
    • 引入新的字段类型 Text/Keyword 来替换 String；
    • 限制索引请求大小，避免大量并发请求压垮 ES；
    • 限制单个请求的 shards 数量，默认 1000 个。

  • 2017 年 8 月 31 日，发布 6.0.0 版本，具有如下重要特性：

  • 稀疏性 Doc Values 的支持；

    • Index Sorting，即索引阶段的排序；

  • 顺序号的支持，每个 es 的操作都有一个顺序编号（类似增量设计）；

    • 无缝滚动升级；

  • 从 6.0 开始不支持一个 index 里面存在多个 type；

    • Index-template inheritance，索引版本的继承，目前索引模板是所有匹配的都会合并，这样会造成索引模板有一些冲突问题， 6.0 将会只匹配一个，索引创建时也会进行验证；
    • Load aware shard routing， 基于负载的请求路由，目前的搜索请求是全节点轮询，那么性能最慢的节点往往会造成整体的延迟增加，新的实现方式将基于队列的耗费时间自动调节队列长度，负载高的节点的队列长度将减少，让其他节点分摊更多的压力，搜索和索引都将基于这种机制；
    • 已经关闭的索引将也支持 replica 的自动处理，确保数据可靠。

  • 2019 年 4 月 10 日，发布 7.0.0 版本，具有如下重要特性：

  • 集群连接变化：TransportClient 被废弃，es7 的 java 代码，只能使用 restclient；对于 java 编程，建议采用 High-level-rest-client 的方式操作 ES 集群；

    • ES 程序包默认打包 jdk：7.x 版本的程序包大小变成 300MB+，对比 6.x，包大了 200MB+，这正是 JDK 的大小；

  • 采用基于 Lucene 9.0；

    • 正式废除单个索引下多 Type 的支持，es6 时，官方就提到了 es7 会删除 type，并且 es6 时，已经规定每一个 index 只能有一个 type。在 es7 中，使用默认的 _doc 作为 type，官方说在 8.x 版本会彻底移除 type。api 请求方式也发送变化，如获得某索引的某 ID 的文档：GET index/_doc/id 其中 index 和 id 为具体的值；

  • 引入了真正的内存断路器，它可以更精准地检测出无法处理的请求，并防止它们使单个节点不稳定；

    • Zen2 是 Elasticsearch 的全新集群协调层，提高了可靠性、性能和用户体验，变得更快、更安全，并更易于使用。

# Elasticsearch 概念

下列有一些概念是 Elasticsearch 的核心。从一开始就理解这些概念将极大地帮助简化学习 Elasticsearch 的过程。

# 近实时（NRT）

Elasticsearch 是一个近乎实时的搜索平台。这意味着从索引文档到可搜索文档的时间有一点延迟（通常是一秒）。

# 索引（Index）

索引在不同语境，有着不同的含义

  • 索引（名词）：一个 索引 类似于传统关系数据库中的一个 数据库 ，是一个存储关系型文档的容器。 索引 (index) 的复数词为 indices 或 indexes 。索引实际上是指向一个或者多个物理分片的逻辑命名空间 。
  • 索引（动词）：索引一个文档 就是存储一个文档到一个 索引 （名词）中以便被检索和查询。这非常类似于 SQL 语句中的 INSERT 关键词，除了文档已存在时，新文档会替换旧文档情况之外。
  • 倒排索引：关系型数据库通过增加一个索引比如一个 B 树索引到指定的列上，以便提升数据检索速度。Elasticsearch 和 Lucene 使用了一个叫做 倒排索引 的结构来达到相同的目的。

索引的 Mapping 和 Setting

  • Mapping 定义文档字段的类型
  • Setting 定义不同的数据分布

示例：

{
+    "settings": { ... any settings ... },
+    "mappings": {
+        "type_one": { ... any mappings ... },
+        "type_two": { ... any mappings ... },
+        ...
+    }
+}
+

# 倒排索引

img

# index template

index template（索引模板）帮助用户设定 Mapping 和 Setting，并按照一定的规则，自动匹配到新创建的索引之上。

  • 模板仅在一个索引被创建时，才会产生作用。修改模板不会影响已创建的索引。
  • 你可以设定多个索引模板，这些设置会被 merge 在一起。
  • 你可以指定 order 的数值，控制 merge 的过程。

当新建一个索引时

  • 应用 ES 默认的 Mapping 和 Setting
  • 应用 order 数值低的 index template 中的设定
  • 应用 order 数值高的 index template 中的设定，之前的设定会被覆盖
  • 应用创建索引是，用户所指定的 Mapping 和 Setting，并覆盖之前模板中的设定。

示例：创建默认索引模板

PUT _template/template_default
+{
+  "index_patterns": ["*"],
+  "order": 0,
+  "version": 1,
+  "settings": {
+    "number_of_shards": 1,
+    "number_of_replicas": 1
+  }
+}
+
+PUT /_template/template_test
+{
+  "index_patterns": ["test*"],
+  "order": 1,
+  "settings": {
+    "number_of_shards": 1,
+    "number_of_replicas": 2
+  },
+  "mappings": {
+    "date_detection": false,
+    "numeric_detection": true
+  }
+}
+
+# 查看索引模板
+GET /_template/template_default
+GET /_template/temp*
+
+#写入新的数据，index以test开头
+PUT testtemplate/_doc/1
+{
+  "someNumber": "1",
+  "someDate": "2019/01/01"
+}
+GET testtemplate/_mapping
+GET testtemplate/_settings
+
+PUT testmy
+{
+	"settings":{
+		"number_of_replicas":5
+	}
+}
+
+PUT testmy/_doc/1
+{
+  "key": "value"
+}
+
+GET testmy/_settings
+DELETE testmy
+DELETE /_template/template_default
+DELETE /_template/template_test
+

# dynamic template

  • 根据 ES 识别的数据类型，结合字段名称，来动态设定字段类型 +
    • 所有的字符串类型都设定成 Keyword，或者关闭 keyword 字段。
    • is 开头的字段都设置成 boolean
    • long_ 开头的都设置成 long 类型
  • dynamic template 是定义在某个索引的 Mapping 中
  • template 有一个名称
  • 匹配规则是一个数组
  • 为匹配到字段设置 Mapping

示例：

#Dynaminc Mapping 根据类型和字段名
+DELETE my_index
+
+PUT my_index/_doc/1
+{
+  "firstName": "Ruan",
+  "isVIP": "true"
+}
+
+GET my_index/_mapping
+
+DELETE my_index
+PUT my_index
+{
+  "mappings": {
+    "dynamic_templates": [
+      {
+        "strings_as_boolean": {
+          "match_mapping_type": "string",
+          "match": "is*",
+          "mapping": {
+            "type": "boolean"
+          }
+        }
+      },
+      {
+        "strings_as_keywords": {
+          "match_mapping_type": "string",
+          "mapping": {
+            "type": "keyword"
+          }
+        }
+      }
+    ]
+  }
+}
+GET my_index/_mapping
+
+DELETE my_index
+#结合路径
+PUT my_index
+{
+  "mappings": {
+    "dynamic_templates": [
+      {
+        "full_name": {
+          "path_match": "name.*",
+          "path_unmatch": "*.middle",
+          "mapping": {
+            "type": "text",
+            "copy_to": "full_name"
+          }
+        }
+      }
+    ]
+  }
+}
+GET my_index/_mapping
+
+
+PUT my_index/_doc/1
+{
+  "name": {
+    "first": "John",
+    "middle": "Winston",
+    "last": "Lennon"
+  }
+}
+
+GET my_index/_search?q=full_name:John
+DELETE my_index
+

# 类型（Type）

type 是一个逻辑意义上的分类或者叫分区，允许在同一索引中建立多个 type。本质是相当于一个过滤条件，高版本将会废弃 type 概念。

6.0.0 版本及之后，废弃 type

# 文档（Document）

Elasticsearch 是面向文档的，文档是所有可搜索数据的最小单位。

Elasticsearch 使用 JSON (opens new window) 作为文档的序列化格式。

在索引/类型中，可以根据需要存储任意数量的文档。

每个文档都有一个 Unique ID

  • 用户可以自己指定
  • 或通过 Elasticsearch 自动生成

# 文档的元数据

一个文档不仅仅包含它的数据 ，也包含元数据 —— 有关文档的信息。

  • _index：文档在哪存放
  • _type：文档表示的对象类别
  • _id：文档唯一标识
  • _source：文档的原始 Json 数据
  • _all：整合所有字段内容到该字段，已被废除
  • _version：文档的版本信息
  • _score：相关性打分

示例：

{
+  "_index": "megacorp",
+  "_type": "employee",
+  "_id": "1",
+  "_version": 1,
+  "found": true,
+  "_source": {
+    "first_name": "John",
+    "last_name": "Smith",
+    "age": 25,
+    "about": "I love to go rock climbing",
+    "interests": ["sports", "music"]
+  }
+}
+

# 节点（Node）

# 节点简介

一个运行中的 Elasticsearch 实例称为一个节点。

Elasticsearch 实例本质上是一个 Java 进程。一台机器上可以运行多个 Elasticsearch 进程，但是生产环境建议一台机器上只运行一个 Elasticsearch 进程

每个节点都有名字，通过配置文件配置，或启动时通过 -E node.name=node1 指定。

每个节点在启动后，会分配一个 UID，保存在 data 目录下。

# 节点类型

  • 主节点（master node）：每个节点都保存了集群的状态，只有 master 节点才能修改集群的状态信息（保证数据一致性）。集群状态，维护了以下信息： +
    • 所有的节点信息
    • 所有的索引和其相关的 mapping 和 setting 信息
    • 分片的路由信息
  • 候选节点（master eligible node）：master eligible 节点可以参加选主流程。第一个启动的节点，会将自己选举为 mater 节点。 +
    • 每个节点启动后，默认为 master eligible 节点，可以通过配置 node.master: false 禁止
  • 数据节点（data node）：负责保存分片数据。
  • 协调节点（coordinating node）：负责接收客户端的请求，将请求分发到合适的接地那，最终把结果汇集到一起。每个 Elasticsearch 节点默认都是协调节点（coordinating node）。
  • 冷/热节点（warm/hot node）：针对不同硬件配置的数据节点（data node），用来实现 Hot & Warm 架构，降低集群部署的成本。
  • 机器学习节点（machine learning node）：负责执行机器学习的 Job，用来做异常检测。

# 节点配置

配置参数 默认值 说明
node.master true 是否为主节点
node.data true 是否为数据节点
node.ingest true
node.ml true 是否为机器学习节点（需要开启 x-pack）

建议

开发环境中一个节点可以承担多种角色。但是，在生产环境中，节点应该设置为单一角色。

# 集群（Cluster）

# 集群简介

拥有相同 cluster.name 配置的 Elasticsearch 节点组成一个集群。 cluster.name 默认名为 elasticsearch，可以通过配置文件修改，或启动时通过 -E cluster.name=xxx 指定。

当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

当一个节点被选举成为主节点时，它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量增加，它也不会成为瓶颈。 任何节点都可以成为主节点。

作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

# 集群健康

Elasticsearch 的集群监控信息中包含了许多的统计数据，其中最为重要的一项就是 集群健康 ， 它在 status 字段中展示为 green 、 yellow 或者 red 。

在一个不包含任何索引的空集群中，它将会有一个类似于如下所示的返回内容：

{
+  "cluster_name" : "elasticsearch",
+  "status" : "green",
+  "timed_out" : false,
+  "number_of_nodes" : 1,
+  "number_of_data_nodes" : 1,
+  "active_primary_shards" : 5,
+  "active_shards" : 5,
+  "relocating_shards" : 0,
+  "initializing_shards" : 0,
+  "unassigned_shards" : 0,
+  "delayed_unassigned_shards" : 0,
+  "number_of_pending_tasks" : 0,
+  "number_of_in_flight_fetch" : 0,
+  "task_max_waiting_in_queue_millis" : 0,
+  "active_shards_percent_as_number" : 100.0
+}
+

status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：

  • green：所有的主分片和副本分片都正常运行。
  • yellow：所有的主分片都正常运行，但不是所有的副本分片都正常运行。
  • red：有主分片没能正常运行。

# 分片（Shards）

# 分片简介

索引实际上是指向一个或者多个物理分片的逻辑命名空间 。

一个分片是一个底层的工作单元 ，它仅保存了全部数据中的一部分。一个分片可以视为一个 Lucene 的实例，并且它本身就是一个完整的搜索引擎。 我们的文档被存储和索引到分片内，但是应用程序是直接与索引而不是与分片进行交互。

Elasticsearch 是利用分片将数据分发到集群内各处的。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。 当你的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。

# 主分片和副分片

分片分为主分片（Primary Shard）和副分片（Replica Shard）。

主分片：用于解决数据水平扩展的问题。通过主分片，可以将数据分布到集群内不同节点上。

  • 索引内任意一个文档都归属于一个主分片。
  • 主分片数在索引创建时指定，后序不允许修改，除非 Reindex

副分片（Replica Shard）：用于解决数据高可用的问题。副分片是主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。

  • 副分片数可以动态调整
  • 增加副本数，还可以在一定程度上提高服务的可用性（读取的吞吐）

对于生产环境中分片的设定，需要提前做好容量规划

分片数过小

  • 无法水平扩展
  • 单个分片的数量太大，导致数据重新分配耗时

分片数过大

  • 影响搜索结果的相关性打分，影响统计结果的准确性
  • 单节点上过多的分片，会导致资源浪费，同时也会影响性能

# 副本（Replicas）

副本主要是针对主分片（Shards）的复制，Elasticsearch 中主分片可以拥有 0 个或多个的副本。

副本分片的主要目的就是为了故障转移。

分片副本很重要，主要有两个原因：

  • 它在分片或节点发生故障时提供高可用性。因此，副本分片永远不会在与其复制的主分片相同的节点；
  • 副本分片也可以接受搜索的请求，可以并行搜索，从而提高系统的吞吐量。

每个 Elasticsearch 分片都是 Lucene 索引。单个 Lucene 索引中可以包含最大数量的文档。截止 LUCENE-5843，限制是 2,147,483,519（= Integer.MAX_VALUE - 128）文档。您可以使用_cat/shardsAPI 监控分片大小。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch
上次更新: 2023/06/29, 22:27:04
Elasticsearch 快速入门
Elasticsearch 索引

+ ← + Elasticsearch 索引→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/10c674/index.html b/pages/10c674/index.html new file mode 100644 index 00000000..b61fe610 --- /dev/null +++ b/pages/10c674/index.html @@ -0,0 +1,64 @@ + + + + + + MongoDB 索引 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-21
目录

MongoDB 索引

# MongoDB 索引

# MongoDB 索引简介

# 索引的作用

MongoDB 在 collection 数据级别上定义索引。

索引通常能够极大的提高查询的效率。如果没有索引，MongoDB 在读取数据时必须扫描 collection 中的每个 document 并选取那些符合查询条件的记录。

这种扫描全集合的查询是非常低效的，特别是在处理大量的数据时。查询可能要花费几十秒甚至几分钟，这种性能开销是不可接受的。

索引是特殊的数据结构，索引存储在一个易于遍历读取的数据集合中，索引是对数据库表中一列或多列的值进行排序的一种结构。

img

# createIndex() 方法

MongoDB 使用 createIndex() 方法来创建索引。

createIndex() 语法如下：

db.collection.createIndex( <key and index type specification>, <options> )
+

createIndex() 可选参数列表如下：

Parameter Type Description
background Boolean 建索引过程会阻塞其它数据库操作，background 可指定以后台方式创建索引，即增加 "background" 可选参数。 "background" 默认值为false。
unique Boolean 建立的索引是否唯一。指定为 true 创建唯一索引。默认值为false.
name string 索引的名称。如果未指定，MongoDB 的通过连接索引的字段名和排序顺序生成一个索引名称。
dropDups Boolean **3.0+版本已废弃。**在建立唯一索引时是否删除重复记录,指定 true 创建唯一索引。默认值为 false.
sparse Boolean 对文档中不存在的字段数据不启用索引；这个参数需要特别注意，如果设置为 true 的话，在索引字段中不会查询出不包含对应字段的文档.。默认值为 false.
expireAfterSeconds integer 指定一个以秒为单位的数值，完成 TTL 设定，设定集合的生存时间。
v index version 索引的版本号。默认的索引版本取决于 mongod 创建索引时运行的版本。
weights document 索引权重值，数值在 1 到 99,999 之间，表示该索引相对于其他索引字段的得分权重。
default_language string 对于文本索引，该参数决定了停用词及词干和词器的规则的列表。 默认为英语
language_override string 对于文本索引，该参数指定了包含在文档中的字段名，语言覆盖默认的 language，默认值为 language.

【示例】使用 name 作为索引，并且按照降序排序

db.collection.createIndex( { name: -1 } )
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#文档数据库#MongoDB#索引
上次更新: 2023/06/29, 22:27:04
MongoDB 建模示例
MongoDB 复制

+ ← + MongoDB 复制→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/1ae1ca/index.html b/pages/1ae1ca/index.html new file mode 100644 index 00000000..f32b9188 --- /dev/null +++ b/pages/1ae1ca/index.html @@ -0,0 +1,202 @@ + + + + + + SQL 语法高级特性 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-04-27
目录

SQL 语法高级特性

# SQL 语法高级特性

本文针对关系型数据库的基本语法。限于篇幅，本文侧重说明用法，不会展开讲解特性、原理。

本文语法主要针对 Mysql，但大部分的语法对其他关系型数据库也适用。

img

# 连接和组合

# 连接（JOIN）

连接用于连接多个表，使用 JOIN 关键字，并且条件语句使用 ON 而不是 WHERE。

如果一个 JOIN 至少有一个公共字段并且它们之间存在关系，则该 JOIN 可以在两个或多个表上工作。

JOIN 保持基表（结构和数据）不变。连接可以替换子查询，并且比子查询的效率一般会更快。

JOIN 有两种连接类型：内连接和外连接。

sql-join

# 内连接（INNER JOIN）

内连接又称等值连接，使用 INNER JOIN 关键字。在没有条件语句的情况下返回笛卡尔积。

SELECT vend_name, prod_name, prod_price
+FROM vendors INNER JOIN products
+ON vendors.vend_id = products.vend_id;
+
# 自连接（=）

自连接可以看成内连接的一种，只是连接的表是自身而已。自然连接是把同名列通过 = 连接起来的，同名列可以有多个。

SELECT c1.cust_id, c1.cust_name, c1.cust_contact
+FROM customers c1, customers c2
+WHERE c1.cust_name = c2.cust_name
+AND c2.cust_contact = 'Jim Jones';
+
# 自然连接（NATURAL JOIN）

内连接提供连接的列，而自然连接自动连接所有同名列。自然连接使用 NATURAL JOIN 关键字。

SELECT *
+FROM Products
+NATURAL JOIN Customers;
+

# 外连接（OUTER JOIN）

外连接返回一个表中的所有行，并且仅返回来自此表中满足连接条件的那些行，即两个表中的列是相等的。外连接分为左外连接、右外连接、全外连接（Mysql 不支持）。

# 左连接（LEFT JOIN）

左外连接就是保留左表没有关联的行。

SELECT customers.cust_id, orders.order_num
+FROM customers LEFT JOIN orders
+ON customers.cust_id = orders.cust_id;
+
# 右连接（RIGHT JOIN）

右外连接就是保留右表没有关联的行。

SELECT customers.cust_id, orders.order_num
+FROM customers RIGHT JOIN orders
+ON customers.cust_id = orders.cust_id;
+

# 组合（UNION）

UNION 运算符将两个或更多查询的结果组合起来，并生成一个结果集，其中包含来自 UNION 中参与查询的提取行。

UNION 基本规则：

  • 所有查询的列数和列顺序必须相同。
  • 每个查询中涉及表的列的数据类型必须相同或兼容。
  • 通常返回的列名取自第一个查询。

默认会去除相同行，如果需要保留相同行，使用 UNION ALL。

只能包含一个 ORDER BY 子句，并且必须位于语句的最后。

应用场景：

  • 在一个查询中从不同的表返回结构数据。
  • 对一个表执行多个查询，按一个查询返回数据。

组合查询示例：

SELECT cust_name, cust_contact, cust_email
+FROM customers
+WHERE cust_state IN ('IL', 'IN', 'MI')
+UNION
+SELECT cust_name, cust_contact, cust_email
+FROM customers
+WHERE cust_name = 'Fun4All';
+

# JOIN vs UNION

  • JOIN 中连接表的列可能不同，但在 UNION 中，所有查询的列数和列顺序必须相同。
  • UNION 将查询之后的行放在一起（垂直放置），但 JOIN 将查询之后的列放在一起（水平放置），即它构成一个笛卡尔积。

# 函数

🔔 注意：不同数据库的函数往往各不相同，因此不可移植。本节主要以 Mysql 的函数为例。

# 文本处理

函数 说明
LEFT()、RIGHT() 左边或者右边的字符
LOWER()、UPPER() 转换为小写或者大写
LTRIM()、RTIM() 去除左边或者右边的空格
LENGTH() 长度
SOUNDEX() 转换为语音值

其中， SOUNDEX() 可以将一个字符串转换为描述其语音表示的字母数字模式。

SELECT *
+FROM mytable
+WHERE SOUNDEX(col1) = SOUNDEX('apple')
+

# 日期和时间处理

  • 日期格式：YYYY-MM-DD
  • 时间格式：HH:MM:SS
函 数 说 明
AddDate() 增加一个日期（天、周等）
AddTime() 增加一个时间（时、分等）
CurDate() 返回当前日期
CurTime() 返回当前时间
Date() 返回日期时间的日期部分
DateDiff() 计算两个日期之差
Date_Add() 高度灵活的日期运算函数
Date_Format() 返回一个格式化的日期或时间串
Day() 返回一个日期的天数部分
DayOfWeek() 对于一个日期，返回对应的星期几
Hour() 返回一个时间的小时部分
Minute() 返回一个时间的分钟部分
Month() 返回一个日期的月份部分
Now() 返回当前日期和时间
Second() 返回一个时间的秒部分
Time() 返回一个日期时间的时间部分
Year() 返回一个日期的年份部分
mysql> SELECT NOW();
+
2018-4-14 20:25:11
+

# 数值处理

函数 说明
SIN() 正弦
COS() 余弦
TAN() 正切
ABS() 绝对值
SQRT() 平方根
MOD() 余数
EXP() 指数
PI() 圆周率
RAND() 随机数

# 汇总

函 数 说 明
AVG() 返回某列的平均值
COUNT() 返回某列的行数
MAX() 返回某列的最大值
MIN() 返回某列的最小值
SUM() 返回某列值之和

AVG() 会忽略 NULL 行。

使用 DISTINCT 可以让汇总函数值汇总不同的值。

SELECT AVG(DISTINCT col1) AS avg_col
+FROM mytable
+

# 分组

# GROUP BY

GROUP BY 子句将记录分组到汇总行中，GROUP BY 为每个组返回一个记录。

GROUP BY 可以按一列或多列进行分组。

GROUP BY 通常还涉及聚合函数：COUNT，MAX，SUM，AVG 等。

GROUP BY 按分组字段进行排序后，ORDER BY 可以以汇总字段来进行排序。

分组示例：

SELECT cust_name, COUNT(cust_address) AS addr_num
+FROM Customers GROUP BY cust_name;
+

分组后排序示例：

SELECT cust_name, COUNT(cust_address) AS addr_num
+FROM Customers GROUP BY cust_name
+ORDER BY cust_name DESC;
+

# HAVING

HAVING 用于对汇总的 GROUP BY 结果进行过滤。HAVING 要求存在一个 GROUP BY 子句。

WHERE 和 HAVING 可以在相同的查询中。

HAVING vs WHERE：

  • WHERE 和 HAVING 都是用于过滤。
  • HAVING 适用于汇总的组记录；而 WHERE 适用于单个记录。

使用 WHERE 和 HAVING 过滤数据示例：

SELECT cust_name, COUNT(*) AS num
+FROM Customers
+WHERE cust_email IS NOT NULL
+GROUP BY cust_name
+HAVING COUNT(*) >= 1;
+

（以下为 DDL 语句用法）

# 事务

不能回退 SELECT 语句，回退 SELECT 语句也没意义；也不能回退 CREATE 和 DROP 语句。

MySQL 默认采用隐式提交策略（autocommit），每执行一条语句就把这条语句当成一个事务然后进行提交。当出现 START TRANSACTION 语句时，会关闭隐式提交；当 COMMIT 或 ROLLBACK 语句执行后，事务会自动关闭，重新恢复隐式提交。

通过 set autocommit=0 可以取消自动提交，直到 set autocommit=1 才会提交；autocommit 标记是针对每个连接而不是针对服务器的。

事务处理指令：

  • START TRANSACTION - 指令用于标记事务的起始点。
  • SAVEPOINT - 指令用于创建保留点。
  • ROLLBACK TO - 指令用于回滚到指定的保留点；如果没有设置保留点，则回退到 START TRANSACTION 语句处。
  • COMMIT - 提交事务。
  • RELEASE SAVEPOINT：删除某个保存点。
  • SET TRANSACTION：设置事务的隔离级别。

事务处理示例：

-- 开始事务
+START TRANSACTION;
+
+-- 插入操作 A
+INSERT INTO `user`
+VALUES (1, 'root1', 'root1', 'xxxx@163.com');
+
+-- 创建保留点 updateA
+SAVEPOINT updateA;
+
+-- 插入操作 B
+INSERT INTO `user`
+VALUES (2, 'root2', 'root2', 'xxxx@163.com');
+
+-- 回滚到保留点 updateA
+ROLLBACK TO updateA;
+
+-- 提交事务，只有操作 A 生效
+COMMIT;
+

# ACID

# 事务隔离级别

（以下为 DCL 语句用法）

# 权限控制

GRANT 和 REVOKE 可在几个层次上控制访问权限：

  • 整个服务器，使用 GRANT ALL 和 REVOKE ALL；
  • 整个数据库，使用 ON database.*；
  • 特定的表，使用 ON database.table；
  • 特定的列；
  • 特定的存储过程。

新创建的账户没有任何权限。

账户用 username@host 的形式定义，username@% 使用的是默认主机名。

MySQL 的账户信息保存在 mysql 这个数据库中。

USE mysql;
+SELECT user FROM user;
+

# 创建账户

CREATE USER myuser IDENTIFIED BY 'mypassword';
+

# 修改账户名

UPDATE user SET user='newuser' WHERE user='myuser';
+FLUSH PRIVILEGES;
+

# 删除账户

DROP USER myuser;
+

# 查看权限

SHOW GRANTS FOR myuser;
+

# 授予权限

GRANT SELECT, INSERT ON *.* TO myuser;
+

# 删除权限

REVOKE SELECT, INSERT ON *.* FROM myuser;
+

# 更改密码

SET PASSWORD FOR myuser = 'mypass';
+

# 存储过程

存储过程的英文是 Stored Procedure。它可以视为一组 SQL 语句的批处理。一旦存储过程被创建出来，使用它就像使用函数一样简单，我们直接通过调用存储过程名即可。

定义存储过程的语法格式：

CREATE PROCEDURE 存储过程名称 ([参数列表])
+BEGIN
+    需要执行的语句
+END
+

存储过程定义语句类型：

  • CREATE PROCEDURE 用于创建存储过程
  • DROP PROCEDURE 用于删除存储过程
  • ALTER PROCEDURE 用于修改存储过程

# 使用存储过程

创建存储过程的要点：

  • DELIMITER 用于定义语句的结束符
  • 存储过程的 3 种参数类型： +
    • IN：存储过程的入参
    • OUT：存储过程的出参
    • INPUT：既是存储过程的入参，也是存储过程的出参
  • 流控制语句： +
    • BEGIN…END：BEGIN…END 中间包含了多个语句，每个语句都以（;）号为结束符。
    • DECLARE：DECLARE 用来声明变量，使用的位置在于 BEGIN…END 语句中间，而且需要在其他语句使用之前进行变量的声明。
    • SET：赋值语句，用于对变量进行赋值。
    • SELECT…INTO：把从数据表中查询的结果存放到变量中，也就是为变量赋值。每次只能给一个变量赋值，不支持集合的操作。
    • IF…THEN…ENDIF：条件判断语句，可以在 IF…THEN…ENDIF 中使用 ELSE 和 ELSEIF 来进行条件判断。
    • CASE：CASE 语句用于多条件的分支判断。

创建存储过程示例：

DROP PROCEDURE IF EXISTS `proc_adder`;
+DELIMITER ;;
+CREATE DEFINER=`root`@`localhost` PROCEDURE `proc_adder`(IN a int, IN b int, OUT sum int)
+BEGIN
+    DECLARE c int;
+    if a is null then set a = 0;
+    end if;
+
+    if b is null then set b = 0;
+    end if;
+
+    set sum  = a + b;
+END
+;;
+DELIMITER ;
+

使用存储过程示例：

set @b=5;
+call proc_adder(2,@b,@s);
+select @s as sum;
+

# 存储过程的利弊

存储过程的优点：

  • 执行效率高：一次编译多次使用。
  • 安全性强：在设定存储过程的时候可以设置对用户的使用权限，这样就和视图一样具有较强的安全性。
  • 可复用：将代码封装，可以提高代码复用。
  • 性能好
    • 由于是预先编译，因此具有很高的性能。
    • 一个存储过程替代大量 T_SQL 语句 ，可以降低网络通信量，提高通信速率。

存储过程的缺点：

  • 可移植性差：存储过程不能跨数据库移植。由于不同数据库的存储过程语法几乎都不一样，十分难以维护（不通用）。
  • 调试困难：只有少数 DBMS 支持存储过程的调试。对于复杂的存储过程来说，开发和维护都不容易。
  • 版本管理困难：比如数据表索引发生变化了，可能会导致存储过程失效。我们在开发软件的时候往往需要进行版本管理，但是存储过程本身没有版本控制，版本迭代更新的时候很麻烦。
  • 不适合高并发的场景：高并发的场景需要减少数据库的压力，有时数据库会采用分库分表的方式，而且对可扩展性要求很高，在这种情况下，存储过程会变得难以维护，增加数据库的压力，显然就不适用了。

综上，存储过程的优缺点都非常突出，是否使用一定要慎重，需要根据具体应用场景来权衡。

# 触发器

触发器可以视为一种特殊的存储过程。

触发器是一种与表操作有关的数据库对象，当触发器所在表上出现指定事件时，将调用该对象，即表的操作事件触发表上的触发器的执行。

# 触发器特性

可以使用触发器来进行审计跟踪，把修改记录到另外一张表中。

MySQL 不允许在触发器中使用 CALL 语句 ，也就是不能调用存储过程。

BEGIN 和 END

当触发器的触发条件满足时，将会执行 BEGIN 和 END 之间的触发器执行动作。

🔔 注意：在 MySQL 中，分号 ; 是语句结束的标识符，遇到分号表示该段语句已经结束，MySQL 可以开始执行了。因此，解释器遇到触发器执行动作中的分号后就开始执行，然后会报错，因为没有找到和 BEGIN 匹配的 END。

这时就会用到 DELIMITER 命令（DELIMITER 是定界符，分隔符的意思）。它是一条命令，不需要语句结束标识，语法为：DELIMITER new_delemiter。new_delemiter 可以设为 1 个或多个长度的符号，默认的是分号 ;，我们可以把它修改为其他符号，如 $ - DELIMITER $ 。在这之后的语句，以分号结束，解释器不会有什么反应，只有遇到了 $，才认为是语句结束。注意，使用完之后，我们还应该记得把它给修改回来。

NEW 和 OLD

  • MySQL 中定义了 NEW 和 OLD 关键字，用来表示触发器的所在表中，触发了触发器的那一行数据。
  • 在 INSERT 型触发器中，NEW 用来表示将要（BEFORE）或已经（AFTER）插入的新数据；
  • 在 UPDATE 型触发器中，OLD 用来表示将要或已经被修改的原数据，NEW 用来表示将要或已经修改为的新数据；
  • 在 DELETE 型触发器中，OLD 用来表示将要或已经被删除的原数据；
  • 使用方法： NEW.columnName （columnName 为相应数据表某一列名）

# 触发器指令

提示：为了理解触发器的要点，有必要先了解一下创建触发器的指令。

CREATE TRIGGER 指令用于创建触发器。

语法：

CREATE TRIGGER trigger_name
+trigger_time
+trigger_event
+ON table_name
+FOR EACH ROW
+BEGIN
+  trigger_statements
+END;
+

说明：

  • trigger_name：触发器名
  • trigger_time: 触发器的触发时机。取值为 BEFORE 或 AFTER。
  • trigger_event: 触发器的监听事件。取值为 INSERT、UPDATE 或 DELETE。
  • table_name: 触发器的监听目标。指定在哪张表上建立触发器。
  • FOR EACH ROW: 行级监视，Mysql 固定写法，其他 DBMS 不同。
  • trigger_statements: 触发器执行动作。是一条或多条 SQL 语句的列表，列表内的每条语句都必须用分号 ; 来结尾。

创建触发器示例：

DELIMITER $
+CREATE TRIGGER `trigger_insert_user`
+AFTER INSERT ON `user`
+FOR EACH ROW
+BEGIN
+    INSERT INTO `user_history`(user_id, operate_type, operate_time)
+    VALUES (NEW.id, 'add a user',  now());
+END $
+DELIMITER ;
+

查看触发器示例：

SHOW TRIGGERS;
+

删除触发器示例：

DROP TRIGGER IF EXISTS trigger_insert_user;
+

# 游标

游标（CURSOR）是一个存储在 DBMS 服务器上的数据库查询，它不是一条 SELECT 语句，而是被该语句检索出来的结果集。在存储过程中使用游标可以对一个结果集进行移动遍历。

游标主要用于交互式应用，其中用户需要对数据集中的任意行进行浏览和修改。

使用游标的步骤：

  1. 定义游标：通过 DECLARE cursor_name CURSOR FOR <语句> 定义游标。这个过程没有实际检索出数据。
  2. 打开游标：通过 OPEN cursor_name 打开游标。
  3. 取出数据：通过 FETCH cursor_name INTO var_name ... 获取数据。
  4. 关闭游标：通过 CLOSE cursor_name 关闭游标。
  5. 释放游标：通过 DEALLOCATE PREPARE 释放游标。

游标使用示例：

DELIMITER $
+CREATE PROCEDURE getTotal()
+BEGIN
+    DECLARE total INT;
+    -- 创建接收游标数据的变量
+    DECLARE sid INT;
+    DECLARE sname VARCHAR(10);
+    -- 创建总数变量
+    DECLARE sage INT;
+    -- 创建结束标志变量
+    DECLARE done INT DEFAULT false;
+    -- 创建游标
+    DECLARE cur CURSOR FOR SELECT id,name,age from cursor_table where age>30;
+    -- 指定游标循环结束时的返回值
+    DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = true;
+    SET total = 0;
+    OPEN cur;
+    FETCH cur INTO sid, sname, sage;
+    WHILE(NOT done)
+    DO
+        SET total = total + 1;
+        FETCH cur INTO sid, sname, sage;
+    END WHILE;
+
+    CLOSE cur;
+    SELECT total;
+END $
+DELIMITER ;
+
+-- 调用存储过程
+call getTotal();
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#SQL
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/1fc9c4/index.html b/pages/1fc9c4/index.html new file mode 100644 index 00000000..75673e68 --- /dev/null +++ b/pages/1fc9c4/index.html @@ -0,0 +1,62 @@ + + + + + + Redis 实战 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-24
目录

Redis 实战

# Redis 实战

# 一、应用场景

Redis 可以应用于很多场景，这里列举几个经典的应用场景。

# 缓存

缓存是 Redis 最常见的应用场景。

Redis 有多种数据类型，以及丰富的操作命令，并且有着高性能、高可用的特性，非常适合用于分布式缓存。

缓存应用的基本原理，请参考 缓存基本原理 (opens new window) 第四 ~ 第六节内容。

# BitMap 和 BloomFilter

Redis 除了 5 种基本数据类型外，还支持 BitMap 和 BloomFilter（即布隆过滤器，可以通过 Redis Module 支持）。

BitMap 和 BloomFilter 都可以用于解决缓存穿透问题。要点在于：过滤一些不可能存在的数据。

什么是缓存穿透，可以参考：缓存基本原理 (opens new window)

小数据量可以用 BitMap，大数据量可以用布隆过滤器。

# 分布式锁

使用 Redis 作为分布式锁，基本要点如下：

  • 互斥性 - 使用 setnx 抢占锁。
  • 避免永远不释放锁 - 使用 expire 加一个过期时间，避免一直不释放锁，导致阻塞。
  • 原子性 - setnx 和 expire 必须合并为一个原子指令，避免 setnx 后，机器崩溃，没来得及设置 expire，从而导致锁永不释放。

更多分布式锁的实现方式及细节，请参考：分布式锁基本原理 (opens new window)

# 二、技巧

根据 Redis 的特性，在实际应用中，存在一些应用小技巧。

# keys 和 scan

使用 keys 指令可以扫出指定模式的 key 列表。

如果这个 redis 正在给线上的业务提供服务，那使用 keys 指令会有什么问题？

首先，Redis 是单线程的。keys 指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。

这个时候可以使用 scan 指令，scan 指令可以无阻塞的提取出指定模式的 key 列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用 keys 指令长。

不过，增量式迭代命令也不是没有缺点的： 举个例子， 使用 SMEMBERS 命令可以返回集合键当前包含的所有元素， 但是对于 SCAN 这类增量式迭代命令来说， 因为在对键进行增量式迭代的过程中， 键可能会被修改， 所以增量式迭代命令只能对被返回的元素提供有限的保证 。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#KV数据库#Redis
上次更新: 2023/06/29, 22:27:04
Redis 集群
Redis 运维

+ ← + Redis 运维→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/201e43/index.html b/pages/201e43/index.html new file mode 100644 index 00000000..6a69c54a --- /dev/null +++ b/pages/201e43/index.html @@ -0,0 +1,286 @@ + + + + + + ElasticSearch Java API 之 High Level REST Client | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-03-01
目录

ElasticSearch Java API 之 High Level REST Client

# ElasticSearch Java API 之 High Level REST Client

Elasticsearch 官方的 High Level REST Client 在 7.1.5.0 版本废弃。所以本文中的 API 不推荐使用。

# 快速开始

# 引入依赖

在 pom.xml 中引入以下依赖：

<dependency>
+    <groupId>org.elasticsearch.client</groupId>
+    <artifactId>elasticsearch-rest-high-level-client</artifactId>
+    <version>7.17.1</version>
+</dependency>
+

# 创建连接和关闭

// 创建连接
+RestHighLevelClient client = new RestHighLevelClient(
+        RestClient.builder(
+                new HttpHost("localhost", 9200, "http"),
+                new HttpHost("localhost", 9201, "http")));
+
+// 关闭
+client.close();
+

# 索引 API

# 测试准备

public static final String INDEX = "mytest";
+public static final String INDEX_ALIAS = "mytest_alias";
+/**
+ * {@link User} 的 mapping 结构（json形式）
+ */
+public static final String MAPPING_JSON =
+  "{\n" + "  \"properties\": {\n" + "    \"_class\": {\n" + "      \"type\": \"keyword\",\n"
+  + "      \"index\": false,\n" + "      \"doc_values\": false\n" + "    },\n" + "    \"description\": {\n"
+  + "      \"type\": \"text\",\n" + "      \"fielddata\": true\n" + "    },\n" + "    \"enabled\": {\n"
+  + "      \"type\": \"boolean\"\n" + "    },\n" + "    \"name\": {\n" + "      \"type\": \"text\",\n"
+  + "      \"fielddata\": true\n" + "    }\n" + "  }\n" + "}";
+
+@Autowired
+private RestHighLevelClient client;
+

# 创建索引

// 创建索引
+CreateIndexRequest createIndexRequest = new CreateIndexRequest(INDEX);
+
+  // 设置索引的 settings
+  createIndexRequest.settings(
+  Settings.builder().put("index.number_of_shards", 3).put("index.number_of_replicas", 2));
+
+  // 设置索引的 mapping
+  createIndexRequest.mapping(MAPPING_JSON, XContentType.JSON);
+
+  // 设置索引的别名
+  createIndexRequest.alias(new Alias(INDEX_ALIAS));
+
+  AcknowledgedResponse createIndexResponse = client.indices().create(createIndexRequest, RequestOptions.DEFAULT);
+  Assertions.assertTrue(createIndexResponse.isAcknowledged());
+

# 删除索引

// 删除索引
+DeleteIndexRequest deleteIndexRequest = new DeleteIndexRequest(INDEX);
+  AcknowledgedResponse deleteResponse = client.indices().delete(deleteIndexRequest, RequestOptions.DEFAULT);
+  Assertions.assertTrue(deleteResponse.isAcknowledged());
+

# 判断索引是否存在

GetIndexRequest getIndexRequest = new GetIndexRequest(INDEX);
+  Assertions.assertTrue(client.indices().exists(getIndexRequest, RequestOptions.DEFAULT));
+  GetIndexRequest getIndexAliasRequest = new GetIndexRequest(INDEX_ALIAS);
+  Assertions.assertTrue(client.indices().exists(getIndexAliasRequest, RequestOptions.DEFAULT));
+

# 文档 API

# 文档测试准备

public static final String INDEX = "mytest";
+public static final String INDEX_ALIAS = "mytest_alias";
+/**
+ * {@link User} 的 mapping 结构（json形式）
+ */
+public static final String MAPPING_JSON =
+  "{\n" + "  \"properties\": {\n" + "    \"_class\": {\n" + "      \"type\": \"keyword\",\n"
+  + "      \"index\": false,\n" + "      \"doc_values\": false\n" + "    },\n" + "    \"description\": {\n"
+  + "      \"type\": \"text\",\n" + "      \"fielddata\": true\n" + "    },\n" + "    \"enabled\": {\n"
+  + "      \"type\": \"boolean\"\n" + "    },\n" + "    \"name\": {\n" + "      \"type\": \"text\",\n"
+  + "      \"fielddata\": true\n" + "    }\n" + "  }\n" + "}";
+
+@Autowired
+private RestHighLevelClient client;
+
+@BeforeEach
+public void init() throws IOException {
+
+  // 创建索引
+  CreateIndexRequest createIndexRequest = new CreateIndexRequest(INDEX);
+
+  // 设置索引的 settings
+  createIndexRequest.settings(
+  Settings.builder().put("index.number_of_shards", 3).put("index.number_of_replicas", 2));
+
+  // 设置索引的 mapping
+  createIndexRequest.mapping(MAPPING_JSON, XContentType.JSON);
+
+  // 设置索引的别名
+  createIndexRequest.alias(new Alias(INDEX_ALIAS));
+
+  AcknowledgedResponse response = client.indices().create(createIndexRequest, RequestOptions.DEFAULT);
+  Assertions.assertTrue(response.isAcknowledged());
+
+  // 判断索引是否存在
+  GetIndexRequest getIndexRequest = new GetIndexRequest(INDEX_ALIAS);
+  Assertions.assertTrue(client.indices().exists(getIndexRequest, RequestOptions.DEFAULT));
+  GetIndexRequest getIndexAliasRequest = new GetIndexRequest(INDEX_ALIAS);
+  Assertions.assertTrue(client.indices().exists(getIndexAliasRequest, RequestOptions.DEFAULT));
+  }
+
+@AfterEach
+public void destroy() throws IOException {
+  // 删除索引
+  DeleteIndexRequest request = new DeleteIndexRequest(INDEX);
+  AcknowledgedResponse response = client.indices().delete(request, RequestOptions.DEFAULT);
+  Assertions.assertTrue(response.isAcknowledged());
+  }
+

# 创建文档

RestHighLevelClient Api 使用 IndexRequest 来构建创建文档的请求参数。

【示例】创建 id 为 1 的文档

IndexRequest request = new IndexRequest("product");
+  request.id("1");
+  Product product = new Product();
+  product.setName("机器人");
+  product.setDescription("人工智能机器人");
+  product.setEnabled(true);
+  String jsonString = JSONUtil.toJsonStr(product);
+  request.source(jsonString, XContentType.JSON);
+

同步执行

IndexResponse indexResponse = client.index(request, RequestOptions.DEFAULT);
+

异步执行

// 异步执行
+client.indexAsync(request, RequestOptions.DEFAULT, new ActionListener<IndexResponse>() {
+@Override
+public void onResponse(IndexResponse indexResponse) {
+  System.out.println(indexResponse);
+  }
+
+@Override
+public void onFailure(Exception e) {
+  System.out.println("执行失败");
+  }
+  });
+

# 删除文档

RestHighLevelClient Api 使用 DeleteRequest 来构建删除文档的请求参数。

【示例】删除 id 为 1 的文档

DeleteRequest deleteRequest = new DeleteRequest(INDEX_ALIAS, "1");
+

同步执行

DeleteResponse deleteResponse = client.delete(deleteRequest, RequestOptions.DEFAULT);
+  System.out.println(deleteResponse);
+

异步执行

client.deleteAsync(deleteRequest, RequestOptions.DEFAULT, new ActionListener<DeleteResponse>() {
+@Override
+public void onResponse(DeleteResponse deleteResponse) {
+  System.out.println(deleteResponse);
+  }
+
+@Override
+public void onFailure(Exception e) {
+  System.out.println("执行失败");
+  }
+  });
+

# 更新文档

RestHighLevelClient Api 使用 UpdateRequest 来构建更新文档的请求参数。

【示例】更新 id 为 1 的文档

UpdateRequest updateRequest = new UpdateRequest(INDEX_ALIAS, "1");
+  Product product3 = new Product();
+  product3.setName("扫地机器人");
+  product3.setDescription("人工智能扫地机器人");
+  product3.setEnabled(true);
+  String jsonString2 = JSONUtil.toJsonStr(product3);
+  updateRequest.doc(jsonString2, XContentType.JSON);
+

同步执行

UpdateResponse updateResponse = client.update(updateRequest, RequestOptions.DEFAULT);
+  System.out.println(updateResponse);
+

异步执行

client.updateAsync(updateRequest, RequestOptions.DEFAULT, new ActionListener<UpdateResponse>() {
+@Override
+public void onResponse(UpdateResponse updateResponse) {
+  System.out.println(updateResponse);
+  }
+
+@Override
+public void onFailure(Exception e) {
+  System.out.println("执行失败");
+  }
+  });
+

# 查看文档

RestHighLevelClient Api 使用 GetRequest 来构建查看文档的请求参数。

【示例】查看 id 为 1 的文档

GetRequest getRequest = new GetRequest(INDEX_ALIAS, "1");
+

同步执行

GetResponse getResponse = client.get(getRequest, RequestOptions.DEFAULT);
+

异步执行

client.getAsync(getRequest, RequestOptions.DEFAULT, new ActionListener<GetResponse>() {
+@Override
+public void onResponse(GetResponse getResponse) {
+  System.out.println(getResponse);
+  }
+
+@Override
+public void onFailure(Exception e) {
+  System.out.println("执行失败");
+  }
+});
+

# 获取匹配条件的记录总数

@Test
+@DisplayName("获取匹配条件的记录总数")
+public void count() throws IOException {
+    SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
+    sourceBuilder.query(QueryBuilders.matchPhraseQuery("customer_gender", "MALE"));
+    sourceBuilder.trackTotalHits(true);
+
+    CountRequest countRequest = new CountRequest(INDEX);
+    countRequest.source(sourceBuilder);
+
+    CountResponse countResponse = client.count(countRequest, RequestOptions.DEFAULT);
+    long count = countResponse.getCount();
+    System.out.println("命中记录数：" + count);
+}
+

# 分页查询

@ParameterizedTest
+@ValueSource(ints = {0, 1, 2, 3})
+@DisplayName("分页查询测试")
+public void pageTest(int page) throws IOException {
+
+    int size = 10;
+    int offset = page * size;
+    SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
+    sourceBuilder.query(QueryBuilders.matchPhraseQuery("customer_gender", "MALE"));
+    sourceBuilder.from(offset);
+    sourceBuilder.size(size);
+    sourceBuilder.trackTotalHits(true);
+
+    SearchRequest searchRequest = new SearchRequest(INDEX);
+    searchRequest.source(sourceBuilder);
+    SearchResponse response = client.search(searchRequest, RequestOptions.DEFAULT);
+    SearchHit[] hits = response.getHits().getHits();
+    for (SearchHit hit : hits) {
+        KibanaSampleDataEcommerceBean bean =
+            BeanUtil.mapToBean(hit.getSourceAsMap(), KibanaSampleDataEcommerceBean.class, true,
+                               CopyOptions.create());
+        System.out.println(bean);
+    }
+}
+

# 条件查询

@Test
+@DisplayName("条件查询")
+public void matchPhraseQuery() throws IOException {
+    SearchRequest searchRequest = new SearchRequest(INDEX);
+    SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
+
+    BoolQueryBuilder boolQueryBuilder = QueryBuilders.boolQuery();
+    boolQueryBuilder.must(QueryBuilders.matchPhraseQuery("customer_last_name", "Jensen"));
+    sourceBuilder.query(boolQueryBuilder);
+    sourceBuilder.trackTotalHits(true);
+    searchRequest.source(sourceBuilder);
+    SearchResponse response = client.search(searchRequest, RequestOptions.DEFAULT);
+    SearchHit[] hits = response.getHits().getHits();
+    for (SearchHit hit : hits) {
+        KibanaSampleDataEcommerceBean bean =
+            BeanUtil.mapToBean(hit.getSourceAsMap(), KibanaSampleDataEcommerceBean.class, true,
+                               CopyOptions.create());
+        System.out.println(bean);
+    }
+}
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#API
上次更新: 2023/06/29, 22:27:04
Elasticsearch Rest API
Elasticsearch 集群和分片

+ ← + Elasticsearch 集群和分片→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/22f2e3/index.html b/pages/22f2e3/index.html new file mode 100644 index 00000000..0ee0ac66 --- /dev/null +++ b/pages/22f2e3/index.html @@ -0,0 +1,59 @@ + + + + + + 关系型数据库综合知识 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-07-16
目录

关系型数据库综合知识

# 关系型数据库综合知识

# 📖 内容

# 关系型数据库面试总结 💯

# SQL 语法基础特性

# SQL 语法高级特性

# 扩展 SQL

# SQL Cheat Sheet

# 📚 资料

# 🚪 传送

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/24baff/index.html b/pages/24baff/index.html new file mode 100644 index 00000000..e37548bb --- /dev/null +++ b/pages/24baff/index.html @@ -0,0 +1,155 @@ + + + + + + Elasticsearch 排序 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-01-19
目录

Elasticsearch 排序

# Elasticsearch 排序

在 Elasticsearch 中，默认排序是按照相关性的评分（_score）进行降序排序，也可以按照字段的值排序、多级排序、多值字段排序、基于 geo（地理位置）排序以及自定义脚本排序，除此之外，对于相关性的评分也可以用 rescore 二次、三次打分，它可以限定重新打分的窗口大小（window size），并针对作用范围内的文档修改其得分，从而达到精细化控制结果相关性的目的。

# 默认相关性排序

在 Elasticsearch 中，默认情况下，文档是按照相关性得分倒序排列的，其对应的相关性得分字段用 _score 来表示，它是浮点数类型，_score 评分越高，相关性越高。评分模型的选择可以通过 similarity 参数在映射中指定。

相似度算法可以按字段指定，只需在映射中为不同字段选定即可，如果要修改已有字段的相似度算法，只能通过为数据重新建立索引来达到目的。关于更多 es 相似度算法可以参考 深入理解 es 相似度算法（相关性得分计算） (opens new window)。

# TF-IDF 模型

Elasticsearch 在 5.4 版本以前，text 类型的字段，默认采用基于 tf-idf 的向量空间模型。

在开始计算得分之时，Elasticsearch 使用了被搜索词条的频率以及它有多常见来影响得分。一个简短的解释是，一个词条出现在某个文档中的次数越多，它就越相关；但是，如果该词条出现在不同的文档的次数越多，它就越不相关。这一点被称为 TF-IDF，TF 是词频（term frequency），IDF 是逆文档频率（inverse document frequency）。

考虑给一篇文档打分的首要方式，是统计一个词条在文本中出现的次数。举个例子，如果在用户的区域搜索关于 Elasticsearch 的 get-together，用户希望频繁提及 Elasticsearch 的分组被优先展示出来。

"We will discuss Elasticsearch at the next Big Data group."
+"Tuesday the Elasticsearch team will gather to answer questions about Elasticsearch."
+

第一个句子提到 Elasticsearch 一次，而第二个句子提到 Elasticsearch 两次，所以包含第二句话的文档应该比包含第一句话的文档拥有更高的得分。如果我们要按照数量来讨论，第一句话的词频（TF）是 1，而第二句话的词频将是 2。

逆文档频率比文档词频稍微复杂一点。这个听上去很酷炫的描述意味着，如果一个分词（通常是单词，但不一定是）在索引的不同文档中出现越多的次数，那么它就越不重要。使用如下例子更容易解释这一点。

"We use Elasticsearch to power the search for our website."
+"The developers like Elasticsearch so far."
+"The scoring of documents is calculated by the scoring formula."
+

如上述例子，需要理解以下几点：

  • 词条 “Elasticsearch” 的文档频率是 2（因为它出现在两篇文档中）。文档频率的逆源自得分乘以 1/DF，这里 DF 是该词条的文档频率。这就意味着，由于词条拥有更高的文档频率，它的权重就会降低。
  • 词条 “the” 的文档频率是 3，因为它出现在所有的三篇文档中。请注意，尽管 “the” 在最后一篇文档中出现了两次，它的文档频率还是 3。这是因为，逆文档频率只检查一个词条是否出现在某文档中，而不检查它出现多少次。那个应该是词频所关心的事情。

逆文档频率是一个重要的因素，用于平衡词条的词频。举个例子，考虑有一个用户搜索词条 “the score”，单词 the 几乎出现在每个普通的英语文本中，如果它不被均衡一下，单词 the 的频率要完全淹没单词 score 的频率。逆文档频率 IDF 均衡了 the 这种常见词的相关性影响，所以实际的相关性得分将会对查询的词条有一个更准确的描述。

一旦词频 TF 和逆文档频率 IDF 计算完成，就可以使用 TF-IDF 公式来计算文档的得分。

# BM25 模型

Elasticsearch 在 5.4 版本之后，针对 text 类型的字段，默认采用的是 BM25 评分模型，而不是基于 tf-idf 的向量空间模型，评分模型的选择可以通过 similarity 参数在映射中指定。

# 字段的值排序

在 Elasticsearch 中按照字段的值排序，可以利用 sort 参数实现。

GET books/_search
+{
+  "sort": {
+    "price": {
+      "order": "desc"
+    }
+  }
+}
+

返回结果如下：

{
+  "took": 132,
+  "timed_out": false,
+  "_shards": {
+    "total": 10,
+    "successful": 10,
+    "skipped": 0,
+    "failed": 0
+  },
+  "hits": {
+    "total": 749244,
+    "max_score": null,
+    "hits": [
+      {
+        "_index": "books",
+        "_type": "book",
+        "_id": "8456479",
+        "_score": null,
+        "_source": {
+          "id": 8456479,
+          "price": 1580.00,
+          ...
+        },
+        "sort": [
+          1580.00
+        ]
+      },
+      ...
+    ]
+  }
+}
+

从如上返回结果，可以看出，max_score 和 _score 字段都返回 null，返回字段多出 sort 字段，包含排序字段的分值。计算 _score 的花销巨大，如果不根据相关性排序，记录 _score 是没有意义的。如果无论如何都要计算 _score，可以将 track_scores 参数设置为 true。

# 多字段排序

如果我们想要结合使用 price、date 和 _score 进行查询，并且匹配的结果首先按照价格排序，然后按照日期排序，最后按照相关性排序，具体示例如下：

GET books/_search
+{
+	"query": {
+		"bool": {
+			"must": {
+				"match": { "content": "java" }
+			},
+			"filter": {
+				"term": { "user_id": 4868438 }
+			}
+		}
+	},
+	"sort": [{
+			"price": {
+				"order": "desc"
+			}
+		}, {
+			"date": {
+				"order": "desc"
+			}
+		}, {
+			"_score": {
+				"order": "desc"
+			}
+		}
+	]
+}
+

排序条件的顺序是很重要的。结果首先按第一个条件排序，仅当结果集的第一个 sort 值完全相同时才会按照第二个条件进行排序，以此类推。

多级排序并不一定包含 _score。你可以根据一些不同的字段进行排序，如地理距离或是脚本计算的特定值。

# 多值字段的排序

一种情形是字段有多个值的排序，需要记住这些值并没有固有的顺序；一个多值的字段仅仅是多个值的包装，这时应该选择哪个进行排序呢？

对于数字或日期，你可以将多值字段减为单值，这可以通过使用 min、max、avg 或是 sum 排序模式。例如你可以按照每个 date 字段中的最早日期进行排序，通过以下方法：

"sort": {
+  "dates": {
+    "order": "asc",
+    "mode":  "min"
+  }
+}
+

# 地理位置上的距离排序

es 的地理位置排序使用 _geo_distance 来进行距离排序，如下示例：

{
+  "sort" : [
+    {
+      "_geo_distance" : {
+        "es_location_field" : [116.407526, 39.904030],
+        "order" : "asc",
+        "unit" : "km",
+        "mode" : "min",
+        "distance_type" : "plane"
+      }
+    }
+  ],
+  "query" : {
+    ......
+  }
+}
+

_geo_distance 的选项具体如下：

  • 如上的 es_location_field 指的是 es 存储经纬度数据的字段名。
  • order：指定按距离升序或降序，分别对应 asc 和 desc。
  • unit：计算距离值的单位，默认是 m，表示米（meters），其它可选项有 mi、cm、mm、NM、km、ft、yd 和 in。
  • mode：针对数组数据（多个值）时，指定的取值模式，可选值有 min、max、sum、avg 和 median，当排序采用升序时，默认为 min；排序采用降序时，默认为 max。
  • distance_type：用来设置如何计算距离，它的可选项有 sloppy_arc、arc 和 plane，默认为 sloppy_arc，arc 它相对更精确些，但速度会明显下降，plane 则是计算快，但是长距离计算相对不准确。
  • ignore_unmapped：未映射字段时，是否忽略处理，可选项有 true 和 false；默认为 false，表示如果未映射字段，查询将引发异常；若设置 true，将忽略未映射的字段，并且不匹配此查询的任何文档。
  • validation_method：指定检验经纬度数据的方式，可选项有 IGNORE_MALFORMED、COERCE 和 STRICT；IGNORE_MALFORMED 表示可接受纬度或经度无效的地理点，即忽略数据；COERCE 表示另外尝试并推断正确的地理坐标；STRICT 为默认值，表示遇到不正确的地理坐标直接抛出异常。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#排序
上次更新: 2023/06/29, 22:27:04
Elasticsearch 高亮搜索及显示
Elasticsearch 聚合

+ ← + Elasticsearch 聚合→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/263c40/index.html b/pages/263c40/index.html new file mode 100644 index 00000000..cb14bd4b --- /dev/null +++ b/pages/263c40/index.html @@ -0,0 +1,95 @@ + + + + + + HBase 命令 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-02
目录

HBase 命令

# HBase 命令

进入 HBase Shell 控制台：./bin/hbase shell

如果有 kerberos 认证，需要事先使用相应的 keytab 进行一下认证（使用 kinit 命令），认证成功之后再使用 hbase shell 进入可以使用 whoami 命令可查看当前用户.

# 基本命令

  • 获取帮助信息：help
  • 获取命令的详细帮助信息：help 'status'
  • 查看服务器状态：status
  • 查看版本信息：version
  • 查看当前登录用户：whoami

# DDL

# 创建表

【语法】create '表名称','列族名称 1','列族名称 2','列名称 N'

【示例】

# 创建一张名为 test 的表，columnFamliy1、columnFamliy2 是 table1 表的列族。
+create 'test','columnFamliy1','columnFamliy2'
+

# 启用、禁用表

  • 启用表：enable 'test'
  • 禁用表：disable 'test'
  • 检查表是否被启用：is_enabled 'test'
  • 检查表是否被禁用：is_disabled 'test'

# 删除表

注意：删除表前需要先禁用表

disable 'test'
+drop 'test'
+

# 修改表

# 添加列族

命令格式： alter '表名', '列族名'

alter 'test', 'teacherInfo'
+

# 删除列族

命令格式：alter '表名', {NAME => '列族名', METHOD => 'delete'}

alter 'test', {NAME => 'teacherInfo', METHOD => 'delete'}
+

# 更改列族存储版本的限制

默认情况下，列族只存储一个版本的数据，如果需要存储多个版本的数据，则需要修改列族的属性。修改后可通过 desc 命令查看。

alter 'test',{NAME=>'columnFamliy1',VERSIONS=>3}
+

# 查看表

  • 查看所有表：list
  • 查看表的详细信息：describe 'test'
  • 检查表是否存在：exists 'test'

# 增删改

# 插入数据

命令格式：put '表名', '行键','列族:列','值'

注意：如果新增数据的行键值、列族名、列名与原有数据完全相同，则相当于更新操作

put 'test', 'rowkey1', 'columnFamliy1:a', 'valueA'
+put 'test', 'rowkey1', 'columnFamliy1:b', 'valueB'
+put 'test', 'rowkey1', 'columnFamliy1:c', 'valueC'
+
+put 'test', 'rowkey2', 'columnFamliy1:a', 'valueA'
+put 'test', 'rowkey2', 'columnFamliy1:b', 'valueB'
+put 'test', 'rowkey2', 'columnFamliy1:c', 'valueC'
+
+put 'test', 'rowkey3', 'columnFamliy1:a', 'valueA'
+put 'test', 'rowkey3', 'columnFamliy1:b', 'valueB'
+put 'test', 'rowkey3', 'columnFamliy1:c', 'valueC'
+
+put 'test', 'rowkey1', 'columnFamliy2:a', 'valueA'
+put 'test', 'rowkey1', 'columnFamliy2:b', 'valueB'
+put 'test', 'rowkey1', 'columnFamliy2:c', 'valueC'
+

# 获取指定行、列族、列

  • 获取指定行中所有列的数据信息：get 'test','rowkey2'
  • 获取指定行中指定列族下所有列的数据信息：get 'test','rowkey2','columnFamliy1'
  • 获取指定行中指定列的数据信息：get 'test','rowkey2','columnFamliy1:a'

# 删除指定行、列

  • 删除指定行：delete 'test','rowkey2'
  • 删除指定行中指定列的数据：delete 'test','rowkey2','columnFamliy1:a'

# 查询

hbase 中访问数据有两种基本的方式：

  • 按指定 rowkey 获取数据：get 方法；
  • 按指定条件获取数据：scan 方法。

scan 可以设置 begin 和 end 参数来访问一个范围内所有的数据。get 本质上就是 begin 和 end 相等的一种特殊的 scan。

# get 查询

  • 获取指定行中所有列的数据信息：get 'test','rowkey2'
  • 获取指定行中指定列族下所有列的数据信息：get 'test','rowkey2','columnFamliy1'
  • 获取指定行中指定列的数据信息：get 'test','rowkey2','columnFamliy1:a'

# scan 查询

# 查询整表数据

scan 'test'
+

# 查询指定列簇的数据

scan 'test', {COLUMN=>'columnFamliy1'}
+

# 条件查询

# 查询指定列的数据
+scan 'test', {COLUMNS=> 'columnFamliy1:a'}
+

除了列 （COLUMNS） 修饰词外，HBase 还支持 Limit（限制查询结果行数），STARTROW（ROWKEY 起始行，会先根据这个 key 定位到 region，再向后扫描）、STOPROW(结束行)、TIMERANGE（限定时间戳范围）、VERSIONS（版本数）、和 FILTER（按条件过滤行）等。

如下代表从 rowkey2 这个 rowkey 开始，查找下两个行的最新 3 个版本的 name 列的数据：

scan 'test', {COLUMNS=> 'columnFamliy1:a',STARTROW => 'rowkey2',STOPROW => 'rowkey3',LIMIT=>2, VERSIONS=>3}
+

# 条件过滤

Filter 可以设定一系列条件来进行过滤。如我们要查询值等于 24 的所有数据：

scan 'test', FILTER=>"ValueFilter(=,'binary:24')"
+

值包含 valueA 的所有数据：

scan 'test', FILTER=>"ValueFilter(=,'substring:valueA')"
+

列名中的前缀为 b 的：

scan 'test', FILTER=>"ColumnPrefixFilter('b')"
+

FILTER 中支持多个过滤条件通过括号、AND 和 OR 进行组合：

# 列名中的前缀为 b 且列值中包含1998的数据
+scan 'test', FILTER=>"ColumnPrefixFilter('b') AND ValueFilter ValueFilter(=,'substring:A')"
+

PrefixFilter 用于对 Rowkey 的前缀进行判断：

scan 'test', FILTER=>"PrefixFilter('wr')"
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#大数据#HBase
上次更新: 2023/06/29, 22:27:04
HBase 运维
Cassandra

+ ← + Cassandra→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/293175/index.html b/pages/293175/index.html new file mode 100644 index 00000000..007244cf --- /dev/null +++ b/pages/293175/index.html @@ -0,0 +1,255 @@ + + + + + + Elasticsearch 索引 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-02-22
目录

Elasticsearch 索引

# Elasticsearch 索引

# 索引管理操作

Elasticsearch 索引管理主要包括如何进行索引的创建、索引的删除、副本的更新、索引读写权限、索引别名的配置等等内容。

# 索引删除

ES 索引删除操作向 ES 集群的 http 接口发送指定索引的 delete http 请求即可，可以通过 curl 命令，具体如下：

curl -X DELETE http://{es_host}:{es_http_port}/{index}
+

如果删除成功，它会返回如下信息，具体示例如下：

curl -X DELETE http://10.10.10.66:9200/my_index?pretty
+

为了返回的信息便于读取，增加了 pretty 参数：

{
+  "acknowledged" : true
+}
+

# 索引别名

ES 的索引别名就是给一个索引或者多个索引起的另一个名字，典型的应用场景是针对索引使用的平滑切换。

首先，创建索引 my_index，然后将别名 my_alias 指向它，示例如下：

PUT /my_index
+PUT /my_index/_alias/my_alias
+

也可以通过如下形式：

POST /_aliases
+{
+  "actions": [
+    { "add": { "index": "my_index", "alias": "my_alias" }}
+  ]
+}
+

也可以在一次请求中增加别名和移除别名混合使用：

POST /_aliases
+{
+  "actions": [
+    { "remove": { "index": "my_index", "alias": "my_alias" }}
+    { "add": { "index": "my_index_v2", "alias": "my_alias" }}
+  ]
+}
+

需要注意的是，如果别名与索引是一对一的，使用别名索引文档或者查询文档是可以的，但是如果别名和索引是一对多的，使用别名会发生错误，因为 ES 不知道把文档写入哪个索引中去或者从哪个索引中读取文档。

ES 索引别名有个典型的应用场景是平滑切换，更多细节可以查看 Elasticsearch（ES）索引零停机（无需重启）无缝平滑切换的方法 (opens new window)。

# Settings 详解

Elasticsearch 索引的配置项主要分为静态配置属性和动态配置属性，静态配置属性是索引创建后不能修改，而动态配置属性则可以随时修改。

ES 索引设置的 api 为 _settings，完整的示例如下：

PUT /my_index
+{
+  "settings": {
+    "index": {
+      "number_of_shards": "1",
+      "number_of_replicas": "1",
+      "refresh_interval": "60s",
+      "analysis": {
+        "filter": {
+          "tsconvert": {
+            "type": "stconvert",
+            "convert_type": "t2s",
+            "delimiter": ","
+          },
+          "synonym": {
+            "type": "synonym",
+            "synonyms_path": "analysis/synonyms.txt"
+          }
+        },
+        "analyzer": {
+          "ik_max_word_synonym": {
+            "filter": [
+              "synonym",
+              "tsconvert",
+              "standard",
+              "lowercase",
+              "stop"
+            ],
+            "tokenizer": "ik_max_word"
+          },
+          "ik_smart_synonym": {
+            "filter": [
+              "synonym",
+              "standard",
+              "lowercase",
+              "stop"
+            ],
+            "tokenizer": "ik_smart"
+          }
+        },
+			"mapping": {
+				"coerce": "false",
+				"ignore_malformed": "false"
+			},
+			"indexing": {
+				"slowlog": {
+					"threshold": {
+						"index": {
+							"warn": "2s",
+							"info": "1s"
+						}
+					}
+				}
+			},
+			"provided_name": "hospital_202101070533",
+			"query": {
+				"default_field": "timestamp",
+				"parse": {
+					"allow_unmapped_fields": "false"
+				}
+			},
+			"requests": {
+				"cache": {
+					"enable": "true"
+				}
+			},
+			"search": {
+				"slowlog": {
+					"threshold": {
+						"fetch": {
+							"warn": "1s",
+							"info": "200ms"
+						},
+						"query": {
+							"warn": "1s",
+							"info": "500ms"
+						}
+					}
+				}
+			}
+		}
+	}
+}
+

# 固定属性

  • index.creation_date：顾名思义索引的创建时间戳。
  • index.uuid：索引的 uuid 信息。
  • index.version.created：索引的版本号。

# 索引静态配置

  • index.number_of_shards：索引的主分片数，默认值是 5。这个配置在索引创建后不能修改；在 es 层面，可以通过 es.index.max_number_of_shards 属性设置索引最大的分片数，默认为 1024。
  • index.codec：数据存储的压缩算法，默认值为 LZ4，可选择值还有 best_compression，它比 LZ4 可以获得更好的压缩比（即占据较小的磁盘空间，但存储性能比 LZ4 低）。
  • index.routing_partition_size：路由分区数，如果设置了该参数，其路由算法为：( hash(_routing) + hash(_id) % index.routing_parttion_size ) % number_of_shards。如果该值不设置，则路由算法为 hash(_routing) % number_of_shardings，_routing 默认值为 _id。

静态配置里，有重要的部分是配置分析器（config analyzers）。

  • index.analysis

    ：分析器最外层的配置项，内部主要分为 char_filter、tokenizer、filter 和 analyzer。

    • char_filter：定义新的字符过滤器件。
    • tokenizer：定义新的分词器。
    • filter：定义新的 token filter，如同义词 filter。
    • analyzer：配置新的分析器，一般是 char_filter、tokenizer 和一些 token filter 的组合。

# 索引动态配置

  • index.number_of_replicas：索引主分片的副本数，默认值是 1，该值必须大于等于 0，这个配置可以随时修改。
  • index.refresh_interval：执行新索引数据的刷新操作频率，该操作使对索引的最新更改对搜索可见，默认为 1s。也可以设置为 -1 以禁用刷新。更详细信息参考 Elasticsearch 动态修改 refresh_interval 刷新间隔设置 (opens new window)。

# Mapping 详解

在 Elasticsearch 中，Mapping（映射），用来定义一个文档以及其所包含的字段如何被存储和索引，可以在映射中事先定义字段的数据类型、字段的权重、分词器等属性，就如同在关系型数据库中创建数据表时会设置字段的类型。

Mapping 会把 json 文档映射成 Lucene 所需要的扁平格式

一个 Mapping 属于一个索引的 Type

  • 每个文档都属于一个 Type
  • 一个 Type 有一个 Mapping 定义
  • 7.0 开始，不需要在 Mapping 定义中指定 type 信息

# 映射分类

在 Elasticsearch 中，映射可分为静态映射和动态映射。在关系型数据库中写入数据之前首先要建表，在建表语句中声明字段的属性，在 Elasticsearch 中，则不必如此，Elasticsearch 最重要的功能之一就是让你尽可能快地开始探索数据，文档写入 Elasticsearch 中，它会根据字段的类型自动识别，这种机制称为动态映射，而静态映射则是写入数据之前对字段的属性进行手工设置。

# 静态映射

静态映射是在创建索引时手工指定索引映射。静态映射和 SQL 中在建表语句中指定字段属性类似。相比动态映射，通过静态映射可以添加更详细、更精准的配置信息。

如何定义一个 Mapping

PUT /books
+{
+    "mappings": {
+        "type_one": { ... any mappings ... },
+        "type_two": { ... any mappings ... },
+        ...
+    }
+}
+

# 动态映射

动态映射是一种偷懒的方式，可直接创建索引并写入文档，文档中字段的类型是 Elasticsearch 自动识别的，不需要在创建索引的时候设置字段的类型。在实际项目中，如果遇到的业务在导入数据之前不确定有哪些字段，也不清楚字段的类型是什么，使用动态映射非常合适。当 Elasticsearch 在文档中碰到一个以前没见过的字段时，它会利用动态映射来决定该字段的类型，并自动把该字段添加到映射中，根据字段的取值自动推测字段类型的规则见下表：

JSON 格式的数据 自动推测的字段类型
null 没有字段被添加
true or false boolean 类型
浮点类型数字 float 类型
数字 long 类型
JSON 对象 object 类型
数组 由数组中第一个非空值决定
string 有可能是 date 类型（若开启日期检测）、double 或 long 类型、text 类型、keyword 类型

下面举一个例子认识动态 mapping，在 Elasticsearch 中创建一个新的索引并查看它的 mapping，命令如下：

PUT books
+GET books/_mapping
+

此时 books 索引的 mapping 是空的，返回结果如下：

{
+  "books": {
+    "mappings": {}
+  }
+}
+

再往 books 索引中写入一条文档，命令如下：

PUT books/it/1
+{
+	"id": 1,
+	"publish_date": "2019-11-10",
+	"name": "master Elasticsearch"
+}
+

文档写入完成之后，再次查看 mapping，返回结果如下：

{
+  "books": {
+    "mappings": {
+      "properties": {
+        "id": {
+          "type": "long"
+        },
+        "name": {
+          "type": "text",
+          "fields": {
+            "keyword": {
+              "type": "keyword",
+              "ignore_above": 256
+            }
+          }
+        },
+        "publish_date": {
+          "type": "date"
+        }
+      }
+    }
+  }
+}
+

使用动态 mapping 要结合实际业务需求来综合考虑，如果将 Elasticsearch 当作主要的数据存储使用，并且希望出现未知字段时抛出异常来提醒你注意这一问题，那么开启动态 mapping 并不适用。在 mapping 中可以通过 dynamic 设置来控制是否自动新增字段，接受以下参数：

  • true：默认值为 true，自动添加字段。
  • false：忽略新的字段。
  • strict：严格模式，发现新的字段抛出异常。

# 基础类型

类型 关键字
字符串类型 string、text、keyword
数字类型 long、integer、short、byte、double、float、half_float、scaled_float
日期类型 date
布尔类型 boolean
二进制类型 binary
范围类型 range

# 复杂类型

类型 关键字
数组类型 array
对象类型 object
嵌套类型 nested

# 特殊类型

类型 关键字
地理类型 geo_point
地理图形类型 geo_shape
IP 类型 ip
范围类型 completion
令牌计数类型 token_count
附件类型 attachment
抽取类型 percolator

# Mapping 属性

Elasticsearch 的 mapping 中的字段属性非常多，具体如下表格：

| 属性名 | 描述 | +| :- | :- | | +| type | 字段类型，常用的有 text、integer 等等。 | +| index | 当前字段是否被作为索引。可选值为 true，默认为 true。 | +| store | 是否存储指定字段，可选值为 true | false，设置 true 意味着需要开辟单独的存储空间为这个字段做存储，而且这个存储是独立于 _source 的存储的。 | +| norms | 是否使用归一化因子，可选值为 true | false，不需要对某字段进行打分排序时，可禁用它，节省空间；type 为 text 时，默认为 true；而 type 为 keyword 时，默认为 false。 | +| index_options | 索引选项控制添加到倒排索引（Inverted Index）的信息，这些信息用于搜索（Search）和高亮显示：docs：只索引文档编号(Doc Number)；freqs：索引文档编号和词频率（term frequency）；positions：索引文档编号，词频率和词位置（序号）；offsets：索引文档编号，词频率，词偏移量（开始和结束位置）和词位置（序号）。默认情况下，被分析的字符串（analyzed string）字段使用 positions，其他字段默认使用 docs。此外，需要注意的是 index_option 是 elasticsearch 特有的设置属性；临近搜索和短语查询时，index_option 必须设置为 offsets，同时高亮也可使用 postings highlighter。 | +| term_vector | 索引选项控制词向量相关信息：no：默认值，表示不存储词向量相关信息；yes：只存储词向量信息；with_positions：存储词项和词项位置；with_offsets：存储词项和字符偏移位置；with_positions_offsets：存储词项、词项位置、字符偏移位置。term_vector 是 lucene 层面的索引设置。 | +| similarity | 指定文档相似度算法（也可以叫评分模型）：BM25：ES 5 之后的默认设置。 | +| copy_to | 复制到自定义 _all 字段，值是数组形式，即表明可以指定多个自定义的字段。 | +| analyzer | 指定索引和搜索时的分析器，如果同时指定 search_analyzer 则搜索时会优先使用 search_analyzer。 | +| search_analyzer | 指定搜索时的分析器，搜索时的优先级最高。 | +| null_value | 用于需要对 Null 值实现搜索的场景，只有 Keyword 类型支持此配置。 |

# 索引查询

# 多个 index、多个 type 查询

Elasticsearch 的搜索 api 支持一个索引（index）的多个类型（type）查询以及**多个索引（index）**的查询。

例如，我们可以搜索 twitter 索引下面所有匹配条件的所有类型中文档，如下：

GET /twitter/_search?q=user:shay
+

我们也可以搜索一个索引下面指定多个 type 下匹配条件的文档，如下：

GET /twitter/tweet,user/_search?q=user:banon
+

我们也可以搜索多个索引下匹配条件的文档，如下：

GET /twitter,elasticsearch/_search?q=tag:wow
+

此外我们也可以搜索所有索引下匹配条件的文档，用_all 表示所有索引，如下：

GET /_all/_search?q=tag:wow
+

甚至我们可以搜索所有索引及所有 type 下匹配条件的文档，如下：

GET /_search?q=tag:wow
+

# URI 搜索

Elasticsearch 支持用 uri 搜索，可用 get 请求里面拼接相关的参数，并用 curl 相关的命令就可以进行测试。

如下有一个示例：

GET twitter/_search?q=user:kimchy
+

如下是上一个请求的相应实体：

{
+  "timed_out": false,
+  "took": 62,
+  "_shards": {
+    "total": 1,
+    "successful": 1,
+    "skipped": 0,
+    "failed": 0
+  },
+  "hits": {
+    "total": 1,
+    "max_score": 1.3862944,
+    "hits": [
+      {
+        "_index": "twitter",
+        "_type": "_doc",
+        "_id": "0",
+        "_score": 1.3862944,
+        "_source": {
+          "user": "kimchy",
+          "date": "2009-11-15T14:12:12",
+          "message": "trying out Elasticsearch",
+          "likes": 0
+        }
+      }
+    ]
+  }
+}
+

URI 中允许的参数：

名称 描述
q 查询字符串，映射到 query_string 查询
df 在查询中未定义字段前缀时使用的默认字段
analyzer 查询字符串时指定的分词器
analyze_wildcard 是否允许通配符和前缀查询，默认设置为 false
batched_reduce_size 应在协调节点上一次减少的分片结果数。如果请求中潜在的分片数量很大，则应将此值用作保护机制，以减少每个搜索请求的内存开销
default_operator 默认使用的匹配运算符，可以是AND或者OR，默认是OR
lenient 如果设置为 true，将会忽略由于格式化引起的问题（如向数据字段提供文本），默认为 false
explain 对于每个 hit，包含了具体如何计算得分的解释
_source 请求文档内容的参数，默认 true；设置 false 的话，不返回_source 字段，可以使用**_source_include和_source_exclude**参数分别指定返回字段和不返回的字段
stored_fields 指定每个匹配返回的文档中的存储字段，多个用逗号分隔。不指定任何值将导致没有字段返回
sort 排序方式，可以是fieldName、fieldName:asc或者fieldName:desc的形式。fieldName 可以是文档中的实际字段，也可以是诸如_score 字段，其表示基于分数的排序。此外可以指定多个 sort 参数（顺序很重要）
track_scores 当排序时，若设置 true，返回每个命中文档的分数
track_total_hits 是否返回匹配条件命中的总文档数，默认为 true
timeout 设置搜索的超时时间，默认无超时时间
terminate_after 在达到查询终止条件之前，指定每个分片收集的最大文档数。如果设置，则在响应中多了一个 terminated_early 的布尔字段，以指示查询执行是否实际上已终止。默认为 no terminate_after
from 从第几条（索引以 0 开始）结果开始返回，默认为 0
size 返回命中的文档数，默认为 10
search_type 搜索的方式，可以是dfs_query_then_fetch或query_then_fetch。默认为query_then_fetch
allow_partial_search_results 是否可以返回部分结果。如设置为 false，表示如果请求产生部分结果，则设置为返回整体故障；默认为 true，表示允许请求在超时或部分失败的情况下获得部分结果

# 查询流程

在 Elasticsearch 中，查询是一个比较复杂的执行模式，因为我们不知道那些 document 会被匹配到，任何一个 shard 上都有可能，所以一个 search 请求必须查询一个索引或多个索引里面的所有 shard 才能完整的查询到我们想要的结果。

找到所有匹配的结果是查询的第一步，来自多个 shard 上的数据集在分页返回到客户端之前会被合并到一个排序后的 list 列表，由于需要经过一步取 top N 的操作，所以 search 需要进过两个阶段才能完成，分别是 query 和 fetch。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#索引
上次更新: 2023/06/29, 22:27:04
Elasticsearch 简介
Elasticsearch 查询

+ ← + Elasticsearch 查询→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/2d95ce/index.html b/pages/2d95ce/index.html new file mode 100644 index 00000000..bb0a4561 --- /dev/null +++ b/pages/2d95ce/index.html @@ -0,0 +1,73 @@ + + + + + + Elasticsearch 性能优化 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-01-21
目录

Elasticsearch 性能优化

# Elasticsearch 性能优化

Elasticsearch 是当前流行的企业级搜索引擎，设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。作为一个开箱即用的产品，在生产环境上线之后，我们其实不一定能确保其的性能和稳定性。如何根据实际情况提高服务的性能，其实有很多技巧。这章我们分享从实战经验中总结出来的 elasticsearch 性能优化，主要从硬件配置优化、索引优化设置、查询方面优化、数据结构优化、集群架构优化等方面讲解。

# 硬件配置优化

升级硬件设备配置一直都是提高服务能力最快速有效的手段，在系统层面能够影响应用性能的一般包括三个因素：CPU、内存和 IO，可以从这三方面进行 ES 的性能优化工作。

# CPU 配置

一般说来，CPU 繁忙的原因有以下几个：

  1. 线程中有无限空循环、无阻塞、正则匹配或者单纯的计算；
  2. 发生了频繁的 GC；
  3. 多线程的上下文切换；

大多数 Elasticsearch 部署往往对 CPU 要求不高。因此，相对其它资源，具体配置多少个（CPU）不是那么关键。你应该选择具有多个内核的现代处理器，常见的集群使用 2 到 8 个核的机器。如果你要在更快的 CPUs 和更多的核数之间选择，选择更多的核数更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。

# 内存配置

如果有一种资源是最先被耗尽的，它可能是内存。排序和聚合都很耗内存，所以有足够的堆空间来应付它们是很重要的。即使堆空间是比较小的时候，也能为操作系统文件缓存提供额外的内存。因为 Lucene 使用的许多数据结构是基于磁盘的格式，Elasticsearch 利用操作系统缓存能产生很大效果。

64 GB 内存的机器是非常理想的，但是 32 GB 和 16 GB 机器也是很常见的。少于 8 GB 会适得其反（你最终需要很多很多的小机器），大于 64 GB 的机器也会有问题。

由于 ES 构建基于 lucene，而 lucene 设计强大之处在于 lucene 能够很好的利用操作系统内存来缓存索引数据，以提供快速的查询性能。lucene 的索引文件 segements 是存储在单文件中的，并且不可变，对于 OS 来说，能够很友好地将索引文件保持在 cache 中，以便快速访问；因此，我们很有必要将一半的物理内存留给 lucene；另一半的物理内存留给 ES（JVM heap）。

# 内存分配

当机器内存小于 64G 时，遵循通用的原则，50% 给 ES，50% 留给 lucene。

当机器内存大于 64G 时，遵循以下原则：

  • 如果主要的使用场景是全文检索，那么建议给 ES Heap 分配 4~32G 的内存即可；其它内存留给操作系统，供 lucene 使用（segments cache），以提供更快的查询性能。
  • 如果主要的使用场景是聚合或排序，并且大多数是 numerics，dates，geo_points 以及 not_analyzed 的字符类型，建议分配给 ES Heap 分配 4~32G 的内存即可，其它内存留给操作系统，供 lucene 使用，提供快速的基于文档的聚类、排序性能。
  • 如果使用场景是聚合或排序，并且都是基于 analyzed 字符数据，这时需要更多的 heap size，建议机器上运行多 ES 实例，每个实例保持不超过 50% 的 ES heap 设置（但不超过 32 G，堆内存设置 32 G 以下时，JVM 使用对象指标压缩技巧节省空间），50% 以上留给 lucene。

# 禁止 swap

禁止 swap，一旦允许内存与磁盘的交换，会引起致命的性能问题。可以通过在 elasticsearch.yml 中 bootstrap.memory_lock: true，以保持 JVM 锁定内存，保证 ES 的性能。

# GC 设置

保持 GC 的现有设置，默认设置为：Concurrent-Mark and Sweep（CMS），别换成 G1 GC，因为目前 G1 还有很多 BUG。

保持线程池的现有设置，目前 ES 的线程池较 1.X 有了较多优化设置，保持现状即可；默认线程池大小等于 CPU 核心数。如果一定要改，按公式 ( ( CPU 核心数 * 3 ) / 2 ) + 1 设置；不能超过 CPU 核心数的 2 倍；但是不建议修改默认配置，否则会对 CPU 造成硬伤。

# 磁盘

硬盘对所有的集群都很重要，对大量写入的集群更是加倍重要（例如那些存储日志数据的）。硬盘是服务器上最慢的子系统，这意味着那些写入量很大的集群很容易让硬盘饱和，使得它成为集群的瓶颈。

在经济压力能承受的范围下，尽量使用固态硬盘（SSD）。固态硬盘相比于任何旋转介质（机械硬盘，磁带等），无论随机写还是顺序写，都会对 IO 有较大的提升。

如果你正在使用 SSDs，确保你的系统 I/O 调度程序是配置正确的。当你向硬盘写数据，I/O 调度程序决定何时把数据实际发送到硬盘。大多数默认 *nix 发行版下的调度程序都叫做 cfq（完全公平队列）。

调度程序分配时间片到每个进程。并且优化这些到硬盘的众多队列的传递。但它是为旋转介质优化的：机械硬盘的固有特性意味着它写入数据到基于物理布局的硬盘会更高效。

这对 SSD 来说是低效的，尽管这里没有涉及到机械硬盘。但是，deadline 或者 noop 应该被使用。deadline 调度程序基于写入等待时间进行优化，noop 只是一个简单的 FIFO 队列。

这个简单的更改可以带来显著的影响。仅仅是使用正确的调度程序，我们看到了 500 倍的写入能力提升。

如果你使用旋转介质（如机械硬盘），尝试获取尽可能快的硬盘（高性能服务器硬盘，15k RPM 驱动器）。

使用 RAID0 是提高硬盘速度的有效途径，对机械硬盘和 SSD 来说都是如此。没有必要使用镜像或其它 RAID 变体，因为 Elasticsearch 在自身层面通过副本，已经提供了备份的功能，所以不需要利用磁盘的备份功能，同时如果使用磁盘备份功能的话，对写入速度有较大的影响。

最后，避免使用网络附加存储（NAS）。人们常声称他们的 NAS 解决方案比本地驱动器更快更可靠。除却这些声称，我们从没看到 NAS 能配得上它的大肆宣传。NAS 常常很慢，显露出更大的延时和更宽的平均延时方差，而且它是单点故障的。

# 索引优化设置

索引优化主要是在 Elasticsearch 的插入层面优化，Elasticsearch 本身索引速度其实还是蛮快的，具体数据，我们可以参考官方的 benchmark 数据。我们可以根据不同的需求，针对索引优化。

# 批量提交

当有大量数据提交的时候，建议采用批量提交（Bulk 操作）；此外使用 bulk 请求时，每个请求不超过几十 M，因为太大会导致内存使用过大。

比如在做 ELK 过程中，Logstash indexer 提交数据到 Elasticsearch 中，batch size 就可以作为一个优化功能点。但是优化 size 大小需要根据文档大小和服务器性能而定。

像 Logstash 中提交文档大小超过 20MB，Logstash 会将一个批量请求切分为多个批量请求。

如果在提交过程中，遇到 EsRejectedExecutionException 异常的话，则说明集群的索引性能已经达到极限了。这种情况，要么提高服务器集群的资源，要么根据业务规则，减少数据收集速度，比如只收集 Warn、Error 级别以上的日志。

# 增加 Refresh 时间间隔

为了提高索引性能，Elasticsearch 在写入数据的时候，采用延迟写入的策略，即数据先写到内存中，当超过默认 1 秒（index.refresh_interval）会进行一次写入操作，就是将内存中 segment 数据刷新到磁盘中，此时我们才能将数据搜索出来，所以这就是为什么 Elasticsearch 提供的是近实时搜索功能，而不是实时搜索功能。

如果我们的系统对数据延迟要求不高的话，我们可以通过延长 refresh 时间间隔，可以有效地减少 segment 合并压力，提高索引速度。比如在做全链路跟踪的过程中，我们就将 index.refresh_interval 设置为 30s，减少 refresh 次数。再如，在进行全量索引时，可以将 refresh 次数临时关闭，即 index.refresh_interval 设置为-1，数据导入成功后再打开到正常模式，比如 30s。

在加载大量数据时候可以暂时不用 refresh 和 repliccas，index.refresh_interval 设置为-1，index.number_of_replicas 设置为 0。

# 修改 index_buffer_size 的设置

索引缓冲的设置可以控制多少内存分配给索引进程。这是一个全局配置，会应用于一个节点上所有不同的分片上。

indices.memory.index_buffer_size: 10%
+indices.memory.min_index_buffer_size: 48mb
+

indices.memory.index_buffer_size 接受一个百分比或者一个表示字节大小的值。默认是 10%，意味着分配给节点的总内存的 10%用来做索引缓冲的大小。这个数值被分到不同的分片（shards）上。如果设置的是百分比，还可以设置 min_index_buffer_size （默认 48mb）和 max_index_buffer_size（默认没有上限）。

# 修改 translog 相关的设置

一是控制数据从内存到硬盘的操作频率，以减少硬盘 IO。可将 sync_interval 的时间设置大一些。默认为 5s。

index.translog.sync_interval: 5s
+

也可以控制 tranlog 数据块的大小，达到 threshold 大小时，才会 flush 到 lucene 索引文件。默认为 512m。

index.translog.flush_threshold_size: 512mb
+

# 注意 _id 字段的使用

_id 字段的使用，应尽可能避免自定义 _id，以避免针对 ID 的版本管理；建议使用 ES 的默认 ID 生成策略或使用数字类型 ID 做为主键。

# 注意 _all 字段及 _source 字段的使用

**_**all 字段及 _source 字段的使用，应该注意场景和需要，_all 字段包含了所有的索引字段，方便做全文检索，如果无此需求，可以禁用；_source 存储了原始的 document 内容，如果没有获取原始文档数据的需求，可通过设置 includes、excludes 属性来定义放入 _source 的字段。

# 合理的配置使用 index 属性

合理的配置使用 index 属性，analyzed 和 not_analyzed，根据业务需求来控制字段是否分词或不分词。只有 groupby 需求的字段，配置时就设置成 not_analyzed，以提高查询或聚类的效率。

# 减少副本数量

Elasticsearch 默认副本数量为 3 个，虽然这样会提高集群的可用性，增加搜索的并发数，但是同时也会影响写入索引的效率。

在索引过程中，需要把更新的文档发到副本节点上，等副本节点生效后在进行返回结束。使用 Elasticsearch 做业务搜索的时候，建议副本数目还是设置为 3 个，但是像内部 ELK 日志系统、分布式跟踪系统中，完全可以将副本数目设置为 1 个。

# 查询方面优化

Elasticsearch 作为业务搜索的近实时查询时，查询效率的优化显得尤为重要。

# 路由优化

当我们查询文档的时候，Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？它其实是通过下面这个公式来计算出来的。

shard = hash(routing) % number_of_primary_shards
+

routing 默认值是文档的 id，也可以采用自定义值，比如用户 ID。

# 不带 routing 查询

在查询的时候因为不知道要查询的数据具体在哪个分片上，所以整个过程分为 2 个步骤：

  1. 分发：请求到达协调节点后，协调节点将查询请求分发到每个分片上。
  2. 聚合：协调节点搜集到每个分片上查询结果，再将查询的结果进行排序，之后给用户返回结果。

# 带 routing 查询

查询的时候，可以直接根据 routing 信息定位到某个分配查询，不需要查询所有的分配，经过协调节点排序。

向上面自定义的用户查询，如果 routing 设置为 userid 的话，就可以直接查询出数据来，效率提升很多。

# Filter VS Query

尽可能使用过滤器上下文（Filter）替代查询上下文（Query）

  • Query：此文档与此查询子句的匹配程度如何？
  • Filter：此文档和查询子句匹配吗？

Elasticsearch 针对 Filter 查询只需要回答「是」或者「否」，不需要像 Query 查询一样计算相关性分数，同时 Filter 结果可以缓存。

# 深度翻页

在使用 Elasticsearch 过程中，应尽量避免大翻页的出现。

正常翻页查询都是从 from 开始 size 条数据，这样就需要在每个分片中查询打分排名在前面的 from+size 条数据。协同节点收集每个分配的前 from+size 条数据。协同节点一共会受到 N*(from+size) 条数据，然后进行排序，再将其中 from 到 from+size 条数据返回出去。如果 from 或者 size 很大的话，导致参加排序的数量会同步扩大很多，最终会导致 CPU 资源消耗增大。

可以通过使用 Elasticsearch scroll 和 scroll-scan 高效滚动的方式来解决这样的问题。

也可以结合实际业务特点，文档 id 大小如果和文档创建时间是一致有序的，可以以文档 id 作为分页的偏移量，并将其作为分页查询的一个条件。

# 脚本（script）合理使用

我们知道脚本使用主要有 3 种形式，内联动态编译方式、_script 索引库中存储和文件脚本存储的形式；一般脚本的使用场景是粗排，尽量用第二种方式先将脚本存储在 _script 索引库中，起到提前编译，然后通过引用脚本 id，并结合 params 参数使用，即可以达到模型（逻辑）和数据进行了分离，同时又便于脚本模块的扩展与维护。具体 ES 脚本的深入内容请参考 Elasticsearch 脚本模块的详解 (opens new window)。

# 数据结构优化

基于 Elasticsearch 的使用场景，文档数据结构尽量和使用场景进行结合，去掉没用及不合理的数据。

# 尽量减少不需要的字段

如果 Elasticsearch 用于业务搜索服务，一些不需要用于搜索的字段最好不存到 ES 中，这样即节省空间，同时在相同的数据量下，也能提高搜索性能。

避免使用动态值作字段，动态递增的 mapping，会导致集群崩溃；同样，也需要控制字段的数量，业务中不使用的字段，就不要索引。控制索引的字段数量、mapping 深度、索引字段的类型，对于 ES 的性能优化是重中之重。

以下是 ES 关于字段数、mapping 深度的一些默认设置：

index.mapping.nested_objects.limit: 10000
+index.mapping.total_fields.limit: 1000
+index.mapping.depth.limit: 20
+

# Nested Object vs Parent/Child

尽量避免使用 nested 或 parent/child 的字段，能不用就不用；nested query 慢，parent/child query 更慢，比 nested query 慢上百倍；因此能在 mapping 设计阶段搞定的（大宽表设计或采用比较 smart 的数据结构），就不要用父子关系的 mapping。

如果一定要使用 nested fields，保证 nested fields 字段不能过多，目前 ES 默认限制是 50。因为针对 1 个 document，每一个 nested field，都会生成一个独立的 document，这将使 doc 数量剧增，影响查询效率，尤其是 JOIN 的效率。

index.mapping.nested_fields.limit: 50
+
对比 Nested Object Parent/Child
优点 文档存储在一起，因此读取性高 父子文档可以独立更新，互不影响
缺点 更新父文档或子文档时需要更新整个文档 为了维护 join 关系，需要占用部分内存，读取性能较差
场景 子文档偶尔更新，查询频繁 子文档更新频繁

# 选择静态映射，非必需时，禁止动态映射

尽量避免使用动态映射，这样有可能会导致集群崩溃，此外，动态映射有可能会带来不可控制的数据类型，进而有可能导致在查询端出现相关异常，影响业务。

此外，Elasticsearch 作为搜索引擎时，主要承载 query 的匹配和排序的功能，那数据的存储类型基于这两种功能的用途分为两类，一是需要匹配的字段，用来建立倒排索引对 query 匹配用，另一类字段是用做粗排用到的特征字段，如 ctr、点击数、评论数等等。

# 集群架构设计

合理的部署 Elasticsearch 有助于提高服务的整体可用性。

# 主节点、数据节点和协调节点分离

Elasticsearch 集群在架构拓朴时，采用主节点、数据节点和负载均衡节点分离的架构，在 5.x 版本以后，又可将数据节点再细分为“Hot-Warm”的架构模式。

Elasticsearch 的配置文件中有 2 个参数，node.master 和 node.data。这两个参数搭配使用时，能够帮助提供服务器性能。

# 主（master）节点

配置 node.master:true 和 node.data:false，该 node 服务器只作为一个主节点，但不存储任何索引数据。我们推荐每个集群运行 3 个专用的 master 节点来提供最好的弹性。使用时，你还需要将 discovery.zen.minimum_master_nodes setting 参数设置为 2，以免出现脑裂（split-brain）的情况。用 3 个专用的 master 节点，专门负责处理集群的管理以及加强状态的整体稳定性。因为这 3 个 master 节点不包含数据也不会实际参与搜索以及索引操作，在 JVM 上它们不用做相同的事，例如繁重的索引或者耗时，资源耗费很大的搜索。因此不太可能会因为垃圾回收而导致停顿。因此，master 节点的 CPU，内存以及磁盘配置可以比 data 节点少很多的。

# 数据（data）节点

配置 node.master:false 和 node.data:true，该 node 服务器只作为一个数据节点，只用于存储索引数据，使该 node 服务器功能单一，只用于数据存储和数据查询，降低其资源消耗率。

在 Elasticsearch 5.x 版本之后，data 节点又可再细分为“Hot-Warm”架构，即分为热节点（hot node）和暖节点（warm node）。

hot 节点：

hot 节点主要是索引节点（写节点），同时会保存近期的一些频繁被查询的索引。由于进行索引非常耗费 CPU 和 IO，即属于 IO 和 CPU 密集型操作，建议使用 SSD 的磁盘类型，保持良好的写性能；我们推荐部署最小化的 3 个 hot 节点来保证高可用性。根据近期需要收集以及查询的数据量，可以增加服务器数量来获得想要的性能。

将节点设置为 hot 类型需要 elasticsearch.yml 如下配置：

node.attr.box_type: hot
+

如果是针对指定的 index 操作，可以通过 settings 设置 index.routing.allocation.require.box_type: hot 将索引写入 hot 节点。

warm 节点：

这种类型的节点是为了处理大量的，而且不经常访问的只读索引而设计的。由于这些索引是只读的，warm 节点倾向于挂载大量磁盘（普通磁盘）来替代 SSD。内存、CPU 的配置跟 hot 节点保持一致即可；节点数量一般也是大于等于 3 个。

将节点设置为 warm 类型需要 elasticsearch.yml 如下配置：

node.attr.box_type: warm
+

同时，也可以在 elasticsearch.yml 中设置 index.codec:best_compression 保证 warm 节点的压缩配置。

当索引不再被频繁查询时，可通过 index.routing.allocation.require.box_type:warm，将索引标记为 warm，从而保证索引不写入 hot 节点，以便将 SSD 磁盘资源用在刀刃上。一旦设置这个属性，ES 会自动将索引合并到 warm 节点。

# 协调（coordinating）节点

协调节点用于做分布式里的协调，将各分片或节点返回的数据整合后返回。该节点不会被选作主节点，也不会存储任何索引数据。该服务器主要用于查询负载均衡。在查询的时候，通常会涉及到从多个 node 服务器上查询数据，并将请求分发到多个指定的 node 服务器，并对各个 node 服务器返回的结果进行一个汇总处理，最终返回给客户端。在 ES 集群中，所有的节点都有可能是协调节点，但是，可以通过设置 node.master、node.data、node.ingest 都为 false 来设置专门的协调节点。需要较好的 CPU 和较高的内存。

  • node.master:false 和 node.data:true，该 node 服务器只作为一个数据节点，只用于存储索引数据，使该 node 服务器功能单一，只用于数据存储和数据查询，降低其资源消耗率。
  • node.master:true 和 node.data:false，该 node 服务器只作为一个主节点，但不存储任何索引数据，该 node 服务器将使用自身空闲的资源，来协调各种创建索引请求或者查询请求，并将这些请求合理分发到相关的 node 服务器上。
  • node.master:false 和 node.data:false，该 node 服务器即不会被选作主节点，也不会存储任何索引数据。该服务器主要用于查询负载均衡。在查询的时候，通常会涉及到从多个 node 服务器上查询数据，并将请求分发到多个指定的 node 服务器，并对各个 node 服务器返回的结果进行一个汇总处理，最终返回给客户端。

# 关闭 data 节点服务器中的 http 功能

针对 Elasticsearch 集群中的所有数据节点，不用开启 http 服务。将其中的配置参数这样设置，http.enabled:false，同时也不要安装 head, bigdesk, marvel 等监控插件，这样保证 data 节点服务器只需处理创建/更新/删除/查询索引数据等操作。

http 功能可以在非数据节点服务器上开启，上述相关的监控插件也安装到这些服务器上，用于监控 Elasticsearch 集群状态等数据信息。这样做一来出于数据安全考虑，二来出于服务性能考虑。

# 一台服务器上最好只部署一个 node

一台物理服务器上可以启动多个 node 服务器节点（通过设置不同的启动 port），但一台服务器上的 CPU、内存、硬盘等资源毕竟有限，从服务器性能考虑，不建议一台服务器上启动多个 node 节点。

# 集群分片设置

ES 一旦创建好索引后，就无法调整分片的设置，而在 ES 中，一个分片实际上对应一个 lucene 索引，而 lucene 索引的读写会占用很多的系统资源，因此，分片数不能设置过大；所以，在创建索引时，合理配置分片数是非常重要的。一般来说，我们遵循一些原则：

  1. 控制每个分片占用的硬盘容量不超过 ES 的最大 JVM 的堆空间设置（一般设置不超过 32 G，参考上面的 JVM 内存设置原则），因此，如果索引的总容量在 500 G 左右，那分片大小在 16 个左右即可；当然，最好同时考虑原则 2。
  2. 考虑一下 node 数量，一般一个节点有时候就是一台物理机，如果分片数过多，大大超过了节点数，很可能会导致一个节点上存在多个分片，一旦该节点故障，即使保持了 1 个以上的副本，同样有可能会导致数据丢失，集群无法恢复。所以，一般都设置分片数不超过节点数的 3 倍。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#性能
上次更新: 2023/06/29, 22:27:04
Elasticsearch 分析器
Elasticsearch Rest API

+ ← + Elasticsearch Rest API→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/3288f3/index.html b/pages/3288f3/index.html new file mode 100644 index 00000000..c96f176b --- /dev/null +++ b/pages/3288f3/index.html @@ -0,0 +1,218 @@ + + + + + + MongoDB 应用指南 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-07
目录

MongoDB 应用指南

# MongoDB 应用指南

# 简介

MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。

MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。

# MongoDB 发展

  • 1.x - 支持复制和分片
  • 2.x - 更丰富的数据库功能
  • 3.x - WiredTiger 和周边生态
  • 4.x - 支持分布式事务

# MongoDB 和 RDBMS

特性 MongoDB RDBMS
数据模型 文档模型 关系型
CRUD 操作 MQL/SQL SQL
高可用 复制集 集群模式
扩展性 支持分片 数据分区
扩繁方式 垂直扩展+水平扩展 垂直扩展
索引类型 B 树、全文索引、地理位置索引、多键索引、TTL 索引 B 树
数据容量 没有理论上限 千万、亿

# MongoDB 特性

  • 数据是 JSON 结构 +
    • 支持结构化、半结构化数据模型
    • 可以动态响应结构变化
  • 通过副本机制提供高可用
  • 通过分片提供扩容能力

# MongoDB 概念

SQL 术语/概念 MongoDB 术语/概念 解释/说明
database database 数据库
table collection 数据库表/集合
row document 数据记录行/文档
column field 数据字段/域
index index 索引
table joins 表连接,MongoDB 不支持
primary key primary key 主键,MongoDB 自动将_id 字段设置为主键

# 数据库

一个 MongoDB 中可以建立多个数据库。

MongoDB 的默认数据库为"db"，该数据库存储在 data 目录中。

MongoDB 的单个实例可以容纳多个独立的数据库，每一个都有自己的集合和权限，不同的数据库也放置在不同的文件中。

"show dbs" 命令可以显示所有数据的列表。

$ ./mongo
+MongoDBshell version: 3.0.6
+connecting to: test
+> show dbs
+local  0.078GB
+test   0.078GB
+>
+

执行 "db" 命令可以显示当前数据库对象或集合。

$ ./mongo
+MongoDBshell version: 3.0.6
+connecting to: test
+> db
+test
+>
+

运行"use"命令，可以连接到一个指定的数据库。

> use local
+switched to db local
+> db
+local
+>
+

数据库也通过名字来标识。数据库名可以是满足以下条件的任意 UTF-8 字符串。

  • 不能是空字符串（"")。
  • 不得含有 ' '（空格)、.、\$、/、\和 \0 (空字符)。
  • 应全部小写。
  • 最多 64 字节。

有一些数据库名是保留的，可以直接访问这些有特殊作用的数据库。

  • admin：从权限的角度来看，这是"root"数据库。要是将一个用户添加到这个数据库，这个用户自动继承所有数据库的权限。一些特定的服务器端命令也只能从这个数据库运行，比如列出所有的数据库或者关闭服务器。
  • local：这个数据永远不会被复制，可以用来存储限于本地单台服务器的任意集合
  • config：当 Mongo 用于分片设置时，config 数据库在内部使用，用于保存分片的相关信息。

# 文档

文档是一组键值(key-value)对(即 BSON)。MongoDB 的文档不需要设置相同的字段，并且相同的字段不需要相同的数据类型，这与关系型数据库有很大的区别，也是 MongoDB 非常突出的特点。

需要注意的是：

  • 文档中的键/值对是有序的。
  • 文档中的值不仅可以是在双引号里面的字符串，还可以是其他几种数据类型（甚至可以是整个嵌入的文档)。
  • MongoDB 区分类型和大小写。
  • MongoDB 的文档不能有重复的键。
  • 文档的键是字符串。除了少数例外情况，键可以使用任意 UTF-8 字符。

文档键命名规范：

  • 键不能含有 \0 (空字符)。这个字符用来表示键的结尾。
  • . 和 $ 有特别的意义，只有在特定环境下才能使用。
  • 以下划线 _ 开头的键是保留的(不是严格要求的)。

# 集合

集合就是 MongoDB 文档组，类似于 RDBMS （关系数据库管理系统：Relational Database Management System)中的表格。

集合存在于数据库中，集合没有固定的结构，这意味着你在对集合可以插入不同格式和类型的数据，但通常情况下我们插入集合的数据都会有一定的关联性。

合法的集合名：

  • 集合名不能是空字符串""。
  • 集合名不能含有 \0 字符（空字符)，这个字符表示集合名的结尾。
  • 集合名不能以"system."开头，这是为系统集合保留的前缀。
  • 用户创建的集合名字不能含有保留字符。有些驱动程序的确支持在集合名里面包含，这是因为某些系统生成的集合中包含该字符。除非你要访问这种系统创建的集合，否则千万不要在名字里出现 $。

# 元数据

数据库的信息是存储在集合中。它们使用了系统的命名空间：dbname.system.*

在 MongoDB 数据库中名字空间 <dbname>.system.* 是包含多种系统信息的特殊集合(Collection)，如下:

集合命名空间 描述
dbname.system.namespaces 列出所有名字空间。
dbname.system.indexes 列出所有索引。
dbname.system.profile 包含数据库概要(profile)信息。
dbname.system.users 列出所有可访问数据库的用户。
dbname.local.sources 包含复制对端（slave）的服务器信息和状态。

对于修改系统集合中的对象有如下限制。

在 system.indexes 插入数据，可以创建索引。但除此之外该表信息是不可变的(特殊的 drop index 命令将自动更新相关信息)。system.users 是可修改的。system.profile 是可删除的。

# MongoDB 数据类型

数据类型 描述
String 字符串。存储数据常用的数据类型。在 MongoDB 中，UTF-8 编码的字符串才是合法的。
Integer 整型数值。用于存储数值。根据你所采用的服务器，可分为 32 位或 64 位。
Boolean 布尔值。用于存储布尔值（真/假）。
Double 双精度浮点值。用于存储浮点值。
Min/Max keys 将一个值与 BSON（二进制的 JSON）元素的最低值和最高值相对比。
Array 用于将数组或列表或多个值存储为一个键。
Timestamp 时间戳。记录文档修改或添加的具体时间。
Object 用于内嵌文档。
Null 用于创建空值。
Symbol 符号。该数据类型基本上等同于字符串类型，但不同的是，它一般用于采用特殊符号类型的语言。
Date 日期时间。用 UNIX 时间格式来存储当前日期或时间。你可以指定自己的日期时间：创建 Date 对象，传入年月日信息。
Object ID 对象 ID。用于创建文档的 ID。
Binary Data 二进制数据。用于存储二进制数据。
Code 代码类型。用于在文档中存储 JavaScript 代码。
Regular expression 正则表达式类型。用于存储正则表达式。

# MongoDB CRUD

# 数据库操作

# 查看所有数据库

show dbs
+

# 创建数据库

use <database>
+

如果数据库不存在，则创建数据库，否则切换到指定数据库。

【示例】创建数据库，并插入一条数据

刚创建的数据库 test 并不在数据库的列表中， 要显示它，需要插入一些数据

> use test
+switched to db test
+>
+> show dbs
+admin   0.000GB
+config  0.000GB
+local   0.000GB
+> db.test.insert({"name":"mongodb"})
+WriteResult({ "nInserted" : 1 })
+> show dbs
+admin   0.000GB
+config  0.000GB
+local   0.000GB
+test    0.000GB
+

# 删除数据库

删除当前数据库

db.dropDatabase()
+

# 集合操作

# 查看集合

show collections
+

# 创建集合

db.createCollection(name, options)
+

参数说明：

  • name: 要创建的集合名称
  • options: 可选参数, 指定有关内存大小及索引的选项

options 可以是如下参数：

字段 类型 描述
capped 布尔 （可选）如果为 true，则创建固定集合。固定集合是指有着固定大小的集合，当达到最大值时，它会自动覆盖最早的文档。 当该值为 true 时，必须指定 size 参数。
autoIndexId 布尔 3.2 之后不再支持该参数。（可选）如为 true，自动在 _id 字段创建索引。默认为 false。
size 数值 （可选）为固定集合指定一个最大值，即字节数。 如果 capped 为 true，也需要指定该字段。
max 数值 （可选）指定固定集合中包含文档的最大数量。

在插入文档时，MongoDB 首先检查固定集合的 size 字段，然后检查 max 字段。

> db.createCollection("collection")
+{ "ok" : 1 }
+> show collections
+collection
+

# 删除集合

> db.collection.drop()
+true
+> show collections
+>
+

# 插入文档操作

MongoDB 使用 insert() 方法完成插入操作。

语法格式

# 插入单条记录
+db.<集合>.insertOne(<JSON>)
+# 插入多条记录
+db.<集合>.insertMany([<JSON 1>, <JSON 2>, ..., <JSON N>])
+

【示例】insertOne

> db.color.insertOne({name: "red"})
+{
+        "acknowledged" : true,
+        "insertedId" : ObjectId("5f533ae4e8f16647950fdf43")
+}
+

【示例】insertMany

> db.color.insertMany([
+  {
+    "name": "yellow"
+  },
+  {
+    "name": "blue"
+  }
+])
+{
+        "acknowledged" : true,
+        "insertedIds" : [
+                ObjectId("5f533bcae8f16647950fdf44"),
+                ObjectId("5f533bcae8f16647950fdf45")
+        ]
+}
+>
+

# 查询文档操作

MongoDB 使用 find() 方法完成查询文档操作。

语法格式

db.<集合>.find(<JSON>)
+

查询条件也是 json 形式，如果不设置查询条件，即为全量查询。

# 查询条件

操作 格式 范例 RDBMS 中的类似语句
等于 {<key>:<value>} db.book.find({"pageCount": {$eq: 0}}) where pageCount = 0
不等于 {<key>:{$ne:<value>}} db.book.find({"pageCount": {$ne: 0}}) where likes != 50
大于 {<key>:{$gt:<value>}} db.book.find({"pageCount": {$gt: 0}}) where likes > 50
{<key>:{$gt:<value>}} db.book.find({"pageCount": {$gt: 0}}) where likes > 50 大于或等于
小于 {<key>:{$lt:<value>}} db.book.find({"pageCount": {$lt: 200}}) where likes < 50
小于或等于 {<key>:{$lte:<value>}} db.book.find({"pageCount": {$lte: 200}}) where likes <= 50

说明：

$eq  --------  equal  =
+$ne ----------- not equal  !=
+$gt -------- greater than  >
+$gte --------- gt equal  >=
+$lt -------- less than  <
+$lte --------- lt equal  <=
+

【示例】


+
+# 统计匹配查询条件的记录数
+> db.book.find({"status": "MEAP"}).count()
+68
+

# 查询逻辑条件

（1）and 条件

MongoDB 的 find() 方法可以传入多个键(key)，每个键(key)以逗号隔开，即常规 SQL 的 AND 条件。

语法格式如下：

> db.col.find({key1:value1, key2:value2}).pretty()
+

（2）or 条件

MongoDB OR 条件语句使用了关键字 $or,语法格式如下：

>db.col.find(
+   {
+      $or: [
+         {key1: value1}, {key2:value2}
+      ]
+   }
+).pretty()
+

# 模糊查询

查询 title 包含"教"字的文档：

db.col.find({ title: /教/ })
+

查询 title 字段以"教"字开头的文档：

db.col.find({ title: /^教/ })
+

查询 titl e 字段以"教"字结尾的文档：

db.col.find({ title: /教$/ })
+

# Limit() 方法

如果你需要在 MongoDB 中读取指定数量的数据记录，可以使用 MongoDB 的 Limit 方法，limit()方法接受一个数字参数，该参数指定从 MongoDB 中读取的记录条数。

limit()方法基本语法如下所示：

>db.COLLECTION_NAME.find().limit(NUMBER)
+

# Skip() 方法

我们除了可以使用 limit()方法来读取指定数量的数据外，还可以使用 skip()方法来跳过指定数量的数据，skip 方法同样接受一个数字参数作为跳过的记录条数。

skip() 方法脚本语法格式如下：

>db.COLLECTION_NAME.find().limit(NUMBER).skip(NUMBER)
+

# Sort() 方法

在 MongoDB 中使用 sort() 方法对数据进行排序，sort() 方法可以通过参数指定排序的字段，并使用 1 和 -1 来指定排序的方式，其中 1 为升序排列，而 -1 是用于降序排列。

sort()方法基本语法如下所示：

>db.COLLECTION_NAME.find().sort({KEY:1})
+

注意：skip(), limilt(), sort()三个放在一起执行的时候，执行的顺序是先 sort(), 然后是 skip()，最后是显示的 limit()。

# 更新文档操作

update() 方法用于更新已存在的文档。语法格式如下：

db.collection.update(
+   <query>,
+   <update>,
+   {
+     upsert: <boolean>,
+     multi: <boolean>,
+     writeConcern: <document>
+   }
+)
+

参数说明：

  • query : update 的查询条件，类似 sql update 查询内 where 后面的。
  • update : update 的对象和一些更新的操作符（如$,$inc...）等，也可以理解为 sql update 查询内 set 后面的
  • upsert : 可选，这个参数的意思是，如果不存在 update 的记录，是否插入 objNew,true 为插入，默认是 false，不插入。
  • multi : 可选，mongodb 默认是 false,只更新找到的第一条记录，如果这个参数为 true,就把按条件查出来多条记录全部更新。
  • writeConcern :可选，抛出异常的级别。

【示例】更新文档

db.collection.update({ title: 'MongoDB 教程' }, { $set: { title: 'MongoDB' } })
+

【示例】更新多条相同文档

以上语句只会修改第一条发现的文档，如果你要修改多条相同的文档，则需要设置 multi 参数为 true。

db.collection.update(
+  { title: 'MongoDB 教程' },
+  { $set: { title: 'MongoDB' } },
+  { multi: true }
+)
+

【示例】更多实例

只更新第一条记录：

db.collection.update({ count: { $gt: 1 } }, { $set: { test2: 'OK' } })
+

全部更新：

db.collection.update(
+  { count: { $gt: 3 } },
+  { $set: { test2: 'OK' } },
+  false,
+  true
+)
+

只添加第一条：

db.collection.update(
+  { count: { $gt: 4 } },
+  { $set: { test5: 'OK' } },
+  true,
+  false
+)
+

全部添加进去:

db.collection.update(
+  { count: { $gt: 4 } },
+  { $set: { test5: 'OK' } },
+  true,
+  false
+)
+

全部更新：

db.collection.update(
+  { count: { $gt: 4 } },
+  { $set: { test5: 'OK' } },
+  true,
+  false
+)
+

只更新第一条记录：

db.collection.update(
+  { count: { $gt: 4 } },
+  { $set: { test5: 'OK' } },
+  true,
+  false
+)
+

# 删除文档操作

官方推荐使用 deleteOne() 和 deleteMany() 方法删除数据。

删除 status 等于 A 的全部文档：

db.collection.deleteMany({ status: 'A' })
+

删除 status 等于 D 的一个文档：

db.collection.deleteOne({ status: 'D' })
+

# 索引操作

索引通常能够极大的提高查询的效率，如果没有索引，MongoDB 在读取数据时必须扫描集合中的每个文件并选取那些符合查询条件的记录。

这种扫描全集合的查询效率是非常低的，特别在处理大量的数据时，查询可以要花费几十秒甚至几分钟，这对网站的性能是非常致命的。

索引是特殊的数据结构，索引存储在一个易于遍历读取的数据集合中，索引是对数据库表中一列或多列的值进行排序的一种结构。

MongoDB 使用 createIndex() 方法来创建索引。

createIndex()方法基本语法格式如下所示：

>db.collection.createIndex(keys, options)
+

语法中 Key 值为你要创建的索引字段，1 为指定按升序创建索引，如果你想按降序来创建索引指定为 -1 即可。

>db.col.createIndex({"title":1})
+

createIndex() 方法中你也可以设置使用多个字段创建索引（关系型数据库中称作复合索引）。

>db.col.createIndex({"title":1,"description":-1})
+

createIndex() 接收可选参数，可选参数列表如下：

Parameter Type Description
background Boolean 建索引过程会阻塞其它数据库操作，background 可指定以后台方式创建索引，即增加 "background" 可选参数。 "background" 默认值为false。
unique Boolean 建立的索引是否唯一。指定为 true 创建唯一索引。默认值为false.
name string 索引的名称。如果未指定，MongoDB 的通过连接索引的字段名和排序顺序生成一个索引名称。
dropDups Boolean **3.0+版本已废弃。**在建立唯一索引时是否删除重复记录,指定 true 创建唯一索引。默认值为 false。
sparse Boolean 对文档中不存在的字段数据不启用索引；这个参数需要特别注意，如果设置为 true 的话，在索引字段中不会查询出不包含对应字段的文档.。默认值为 false.
expireAfterSeconds integer 指定一个以秒为单位的数值，完成 TTL 设定，设定集合的生存时间。
v index version 索引的版本号。默认的索引版本取决于 mongod 创建索引时运行的版本。
weights document 索引权重值，数值在 1 到 99,999 之间，表示该索引相对于其他索引字段的得分权重。
default_language string 对于文本索引，该参数决定了停用词及词干和词器的规则的列表。 默认为英语
language_override string 对于文本索引，该参数指定了包含在文档中的字段名，语言覆盖默认的 language，默认值为 language.

# MongoDB 聚合操作

MongoDB 中聚合(aggregate)主要用于处理数据(诸如统计平均值,求和等)，并返回计算后的数据结果。有点类似 sql 语句中的 count(*)。

# 管道

整个聚合运算过程称为管道，它是由多个步骤组成，每个管道

  • 接受一系列文档（原始数据）；
  • 每个步骤对这些文档进行一系列运算；
  • 结果文档输出给下一个步骤；

聚合操作的基本格式

pipeline = [$stage1, $stage1, ..., $stageN];
+
+db.<集合>.aggregate(pipeline, {options});
+

# 聚合步骤

步骤 作用 SQL 等价运算符
$match 过滤 WHERE
$project 投影 AS
$sort 排序 ORDER BY
$group 分组 GROUP BY
$skip / $limit 结果限制 SKIP / LIMIT
$lookup 左外连接 LEFT OUTER JOIN
$unwind 展开数组 N/A
$graphLookup 图搜索 N/A
$facet / $bucket 分面搜索 N/A

【示例】

> db.collection.insertMany([{"title":"MongoDB Overview","description":"MongoDB is no sql database","by_user":"collection","tagsr":["mongodb","database","NoSQL"],"likes":"100"},{"title":"NoSQL Overview","description":"No sql database is very fast","by_user":"collection","tagsr":["mongodb","database","NoSQL"],"likes":"10"},{"title":"Neo4j Overview","description":"Neo4j is no sql database","by_user":"Neo4j","tagsr":["neo4j","database","NoSQL"],"likes":"750"}])
+> db.collection.aggregate([{$group : {_id : "$by_user", num_tutorial : {$sum : 1}}}])
+{ "_id" : null, "num_tutorial" : 3 }
+{ "_id" : "Neo4j", "num_tutorial" : 1 }
+{ "_id" : "collection", "num_tutorial" : 2 }
+

下表展示了一些聚合的表达式:

表达式 描述 实例
$sum 计算总和。 db.mycol.aggregate([{$group : {_id : "$by_user", num_tutorial : {$sum : "$likes"}}}])
$avg 计算平均值 db.mycol.aggregate([{$group : {_id : "$by_user", num_tutorial : {$avg : "$likes"}}}])
$min 获取集合中所有文档对应值得最小值。 db.mycol.aggregate([{$group : {_id : "$by_user", num_tutorial : {$min : "$likes"}}}])
$max 获取集合中所有文档对应值得最大值。 db.mycol.aggregate([{$group : {_id : "$by_user", num_tutorial : {$max : "$likes"}}}])
$push 在结果文档中插入值到一个数组中。 db.mycol.aggregate([{$group : {_id : "$by_user", url : {$push: "$url"}}}])
$addToSet 在结果文档中插入值到一个数组中，但不创建副本。 db.mycol.aggregate([{$group : {_id : "$by_user", url : {$addToSet : "$url"}}}])
$first 根据资源文档的排序获取第一个文档数据。 db.mycol.aggregate([{$group : {_id : "$by_user", first_url : {$first : "$url"}}}])
$last 根据资源文档的排序获取最后一个文档数据 db.mycol.aggregate([{$group : {_id : "$by_user", last_url : {$last : "$url"}}}])

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#文档数据库#MongoDB
上次更新: 2023/06/29, 22:27:04
sqlite
MongoDB 的 CRUD 操作

+ ← + MongoDB 的 CRUD 操作→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/379cd8/index.html b/pages/379cd8/index.html new file mode 100644 index 00000000..6cf8376e --- /dev/null +++ b/pages/379cd8/index.html @@ -0,0 +1,73 @@ + + + + + + Redis 复制 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-24
目录

Redis 复制

# Redis 复制

在 Redis 中，可以通过执行 SLAVEOF 命令或设置 slaveof 选项，让一个服务器去复制（replicate）另一个服务器，其中，后者叫主服务器（master），前者叫从服务器（slave）。

Redis 2.8 以前的复制不能高效处理断线后重复制的情况，而 Redis 2.8 新添的部分重同步可以解决这个问题。

img

# 一、复制简介

Redis 通过 slaveof host port 命令来让一个服务器成为另一个服务器的从服务器。

一个主服务器可以有多个从服务器。不仅主服务器可以有从服务器，从服务器也可以有自己的从服务器， 多个从服务器之间可以构成一个主从链。

一个从服务器只能有一个主服务器，并且不支持主主复制。

可以通过复制功能来让主服务器免于执行持久化操作： 只要关闭主服务器的持久化功能， 然后由从服务器去执行持久化操作即可。

在使用 Redis 复制功能时的设置中，强烈建议在 master 和在 slave 中启用持久化。当不启用时，例如由于非常慢的磁盘性能而导致的延迟问题，应该配置实例来避免重置后自动重启。

从 Redis 2.6 开始， 从服务器支持只读模式， 并且该模式为从服务器的默认模式。

  • 只读模式由 redis.conf 文件中的 slave-read-only 选项控制， 也可以通过 CONFIG SET parameter value (opens new window) 命令来开启或关闭这个模式。
  • 只读从服务器会拒绝执行任何写命令， 所以不会出现因为操作失误而将数据不小心写入到了从服务器的情况。

# 二、旧版复制

Redis 2.8 版本以前实现方式：SYNC 命令

Redis 的复制功能分为同步（sync）和命令传播（command propagate）两个操作：

  • 同步（sync） - 用于将从服务器的数据库状态更新至主服务器当前的数据库状态。
  • 命令传播（command propagate） - 当主服务器的数据库状态被修改，导致主从数据库状态不一致时，让主从服务器的数据库重新回到一致状态。

# 同步

SYNC 命令的执行步骤：

  1. 从服务器向主服务器发送 SYNC 命令。
  2. 收到 SYNC 命令的主服务器执行 BGSAVE 命令，在后台生成一个 RDB 文件，并使用一个缓冲区记录从现在开始执行的所有写命令。
  3. 主服务器执行 BGSAVE 完毕后，主服务器会将生成的 RDB 文件发送给从服务器。从服务器接收并载入 RDB 文件，更新自己的数据库状态。
  4. 主服务器将记录在缓冲区中的所有写命令发送给从服务器，从服务器执行这些写命令，更新自己的数据库状态。

img

# 命令传播

同步操作完成后，主从数据库的数据库状态将达到一致。每当主服务器执行客户端发送的写命令时，主从数据库状态不再一致。需要将写命令发送给从服务器执行，使得二者的数据库状态重新达到一致。

# 旧版复制的缺陷

从服务器对主服务器的复制存在两种情况：

  • 初次复制 - 从服务器以前没有复制过将要复制的主服务器。
  • 断线后重复制 - 处于命令传播阶段的主从服务器因为网络原因而中断了复制，当从服务器通过自动重连重新连上了主服务器后，继续复制主服务器。

对于初次复制，旧版复制功能可用很好完成任务；但是对于断线后重复制，由于每次任然需要生成 RDB 并传输，效率很低。

🔔 注意：SYNC 命令是一个非常耗费资源的操作。

  • 主服务器执行 BGSAVE 命令生成 RDB 文件，这个操作会耗费主服务器大量的 CPU、内存和磁盘 I/O 资源。
  • 主服务器传输 RDB 文件给从服务器，这个操作会耗费主从服务器大量的网络资源，并对主服务器响应时延产生影响。
  • 从服务器载入 RDB 文件期间，会阻塞其他命令请求。

# 三、新版复制

Redis 2.8 版本以后的新实现方式：使用 PSYNC 命令替代 SYNC 命令。

PSYNC 命令具有完整重同步和部分重同步两种模式：

  • 完整重同步（full resychronization） - 用于初次复制。执行步骤与 SYNC 命令基本一致。
  • 部分重同步（partial resychronization） - 用于断线后重复制。如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只需接收并执行这些写命令，即可将主从服务器的数据库状态保持一致。

# 部分重同步

部分重同步功能实现由三个部分构成：

  • 主从服务器的复制偏移量（replication offset）
  • 主服务器的复制积压缓冲区（replication backlog）
  • 服务器的运行 ID

# 复制偏移量

主服务器和从服务器会分别维护一个复制偏移量。

  • 如果主从服务器的复制偏移量相同，则说明二者的数据库状态一致；
  • 反之，则说明二者的数据库状态不一致。

img

# 复制积压缓冲区

复制积压缓冲区是主服务器维护的一个固定长度的先进先出（FIFO）队列，默认大小为 1MB。

复制积压缓冲区会保存一部分最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量。

当从服务器断线重连主服务时，从服务器会通过 PSYNC 命令将自己的复制偏移量 offset 发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作。

  • 如果 offset 之后的数据仍然在复制积压缓冲区，则主服务器对从服务器执行部分重同步操作。
  • 反之，则主服务器对从服务器执行完整重同步操作。

🔔 注意：合理调整复制积压缓冲区的大小

  • Redis 复制积压缓冲区默认大小为 1MB。

  • 复制积压缓冲区的最小大小可以根据公式 second * write_size_per_second 估算。

# 服务器的运行 ID

  • 每个 Redis 服务器，都有运行 ID，用于唯一识别身份。
  • 运行 ID 在服务器启动时自动生成，由 40 个随机的十六进制字符组成。例如：132e358005e29741f8d7b0a42d666aace286edda

从服务器对主服务器进行初次复制时，主服务器会将自己的运行 ID 传送给从服务器，从服务器会将这个运行 ID 保存下来。

当从服务器断线重连一个主服务器时，从服务器会发送之前保存的运行 ID：

  • 如果保存的运行 ID 和当前主服务器的运行 ID 一致，则说明从服务器断线之前连接的就是这个主服务器，主服务器可以继续尝试执行部分重同步操作；
  • 反之，若运行 ID 不一致，则说明从服务器断线之前连接的不是这个主服务器，主服务器将对从服务器执行完整重同步操作。

# PSYNC 命令

了解了部分重同步的实现，PSYNC 的实现就很容易理解了，它的基本工作原理大致如下：

当从服务接收到 SLAVEOF 命令时，先判断从服务器以前是否执行过复制操作。

  • 如果没有复制过任何主服务器，向要复制的主服务器发送 PSYNC ? -1 命令，主动请求进行完整重同步。
  • 反之，向要复制的主服务器发送 PSYNC <runid> <offset> 命令。 +
    • runid 是上一次复制的主服务器的运行 ID。
    • offset 是复制偏移量。

接收到 PSYNC <runid> <offset> 命令的主服务会进行分析：

  • 假如主从服务器的 master run id 相同，并且指定的偏移量（offset）在内存缓冲区中还有效，复制就会从上次中断的点开始继续。
  • 如果其中一个条件不满足，就会进行完全重新同步（在 2.8 版本之前就是直接进行完全重新同步）。

img

# 四、心跳检测

在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令：

REPLCONF ACK <replication_offset>
+

其中，replication_offset 是从服务器当前的复制偏移量。

发送 REPLCONF ACK 命令对于主从服务器有三个作用：

  • 检测主从服务器的网络连接状态。
  • 辅助实现 min-slaves 选项。
  • 检测命令丢失。

# 检测主从连接状态

可以通过发送和接收 REPLCONF ACK 命令来检查主从服务器之间的网络连接是否正常：如果主服务器超过一秒没有收到从服务器发来的 REPLCONF ACK 命令，那么主服务器就知道主从服务器之间的连接出现问题了。

可以通过向主服务器发送 INFO replication 命令，在列出的从服务器列表的 lag 一栏中，可以看到从服务器向主服务器发送 REPLCONF ACK 命令已经过去多少秒。

# 辅助实现 min-slaves 选项

Redis 的 min-slaves-to-write 和 min-slaves-max-lag 两个选项可以防止主服务器在不安全的情况下执行写命令。

【示例】min-slaves 配置项

min-slaves-to-write 3
+min-slaves-max-lag 10
+

以上配置表示：从服务器小于 3 个，或三个从服务器的延迟（lag）都大于等于 10 秒时，主服务器将拒绝执行写命令。

# 检测命令丢失

如果因为网络故障，主服务传播给从服务器的写命令丢失，那么从服务器定时向主服务器发送 REPLCONF ACK 命令时，主服务器将发觉从服务器的复制偏移量少于自己的。然后，主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区中找到从服务器缺少的数据，并将这些数据重新发送给从服务器。

# 五、复制的流程

通过向从服务器发送如下 SLAVEOF 命令，可以让一个从服务器去复制一个主服务器。

SLAVEOF <master_ip> <master_port>
+

# 步骤 1. 设置主从服务器

配置一个从服务器非常简单， 只要在配置文件中增加以下的这一行就可以了：

slaveof 127.0.0.1 6379
+

当然， 你需要将代码中的 127.0.0.1 和 6379 替换成你的主服务器的 IP 和端口号。

另外一种方法是调用 SLAVEOF host port (opens new window) 命令， 输入主服务器的 IP 和端口， 然后同步就会开始：

127.0.0.1:6379> SLAVEOF 127.0.0.1 10086
+OK
+

# 步骤 2. 主从服务器建立 TCP 连接。

# 步骤 3. 发送 PING 检查通信状态。

# 步骤 4. 身份验证。

如果主服务器没有设置 requirepass ，从服务器没有设置 masterauth，则不进行身份验证；反之，则需要进行身份验证。如果身份验证失败，则放弃执行复制工作。

如果主服务器通过 requirepass 选项设置了密码， 那么为了让从服务器的同步操作可以顺利进行， 我们也必须为从服务器进行相应的身份验证设置。

对于一个正在运行的服务器， 可以使用客户端输入以下命令：

config set masterauth <password>
+

要永久地设置这个密码， 那么可以将它加入到配置文件中：

masterauth <password>
+

另外还有几个选项， 它们和主服务器执行部分重同步时所使用的复制流缓冲区有关， 详细的信息可以参考 Redis 源码中附带的 redis.conf 示例文件。

# 步骤 5. 发送端口信息。

从服务器执行 REPLCONF listening-port <port-number> ，向主服务器发送从服务器的监听端口号。

# 步骤 6. 同步。

前文已介绍，此处不赘述。

# 步骤 7. 命令传播。

在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务发送命令：

REPLCONF ACK <replication_coffset>
+

命令的作用：

  • 检测主从服务器的网络连接状态。
  • 辅助实现 min-slave 选项。
  • 检测命令丢失。

# 六、复制的配置项

从 Redis 2.8 开始， 为了保证数据的安全性， 可以通过配置， 让主服务器只在有至少 N 个当前已连接从服务器的情况下， 才执行写命令。

不过， 因为 Redis 使用异步复制， 所以主服务器发送的写数据并不一定会被从服务器接收到， 因此， 数据丢失的可能性仍然是存在的。

以下是这个特性的运作原理：

  • 从服务器以每秒一次的频率 PING 主服务器一次， 并报告复制流的处理情况。
  • 主服务器会记录各个从服务器最后一次向它发送 PING 的时间。
  • 用户可以通过配置， 指定网络延迟的最大值 min-slaves-max-lag ， 以及执行写操作所需的至少从服务器数量 min-slaves-to-write 。

如果至少有 min-slaves-to-write 个从服务器， 并且这些服务器的延迟值都少于 min-slaves-max-lag秒， 那么主服务器就会执行客户端请求的写操作。

你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本： 尽管不能保证写操作的持久性， 但起码丢失数据的窗口会被严格限制在指定的秒数中。

另一方面， 如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件， 那么写操作就不会被执行， 主服务器会向请求执行写操作的客户端返回一个错误。

以下是这个特性的两个选项和它们所需的参数：

  • min-slaves-to-write <number of slaves>
  • min-slaves-max-lag <number of seconds>

详细的信息可以参考 Redis 源码中附带的 redis.conf 示例文件。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#KV数据库#Redis#复制
上次更新: 2023/06/29, 22:27:04
Redis 持久化
Redis 哨兵

+ ← + Redis 哨兵→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/396816/index.html b/pages/396816/index.html new file mode 100644 index 00000000..efa28a30 --- /dev/null +++ b/pages/396816/index.html @@ -0,0 +1,124 @@ + + + + + + Mysql 性能优化 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-03
目录

Mysql 性能优化

# Mysql 性能优化

# 数据结构优化

良好的逻辑设计和物理设计是高性能的基石。

# 数据类型优化

# 数据类型优化基本原则

  • 更小的通常更好 - 越小的数据类型通常会更快，占用更少的磁盘、内存，处理时需要的 CPU 周期也更少。 +
    • 例如：整型比字符类型操作代价低，因而会使用整型来存储 IP 地址，使用 DATETIME 来存储时间，而不是使用字符串。
  • 简单就好 - 如整型比字符型操作代价低。 +
    • 例如：很多软件会用整型来存储 IP 地址。
    • 例如：UNSIGNED 表示不允许负值，大致可以使正数的上限提高一倍。
  • 尽量避免 NULL - 可为 NULL 的列会使得索引、索引统计和值比较都更复杂。

# 类型的选择

  • 整数类型通常是标识列最好的选择，因为它们很快并且可以使用 AUTO_INCREMENT。

  • ENUM 和 SET 类型通常是一个糟糕的选择，应尽量避免。

  • 应该尽量避免用字符串类型作为标识列，因为它们很消耗空间，并且通常比数字类型慢。对于 MD5、SHA、UUID 这类随机字符串，由于比较随机，所以可能分布在很大的空间内，导致 INSERT 以及一些 SELECT 语句变得很慢。

    • 如果存储 UUID ，应该移除 - 符号；更好的做法是，用 UNHEX() 函数转换 UUID 值为 16 字节的数字，并存储在一个 BINARY(16) 的列中，检索时，可以通过 HEX() 函数来格式化为 16 进制格式。

# 表设计

应该避免的设计问题：

  • 太多的列 - 设计者为了图方便，将大量冗余列加入表中，实际查询中，表中很多列是用不到的。这种宽表模式设计，会造成不小的性能代价，尤其是 ALTER TABLE 非常耗时。
  • 太多的关联 - 所谓的实体 - 属性 - 值（EAV）设计模式是一个常见的糟糕设计模式。Mysql 限制了每个关联操作最多只能有 61 张表，但 EAV 模式需要许多自关联。
  • 枚举 - 尽量不要用枚举，因为添加和删除字符串（枚举选项）必须使用 ALTER TABLE。
  • 尽量避免 NULL

# 范式和反范式

范式化目标是尽量减少冗余，而反范式化则相反。

范式化的优点：

  • 比反范式更节省空间
  • 更新操作比反范式快
  • 更少需要 DISTINCT 或 GROUP BY 语句

范式化的缺点：

  • 通常需要关联查询。而关联查询代价较高，如果是分表的关联查询，代价更是高昂。

在真实世界中，很少会极端地使用范式化或反范式化。实际上，应该权衡范式和反范式的利弊，混合使用。

# 索引优化

索引优化应该是查询性能优化的最有效手段。

如果想详细了解索引特性请参考：Mysql 索引 (opens new window)

# 何时使用索引

  • 对于非常小的表，大部分情况下简单的全表扫描更高效。
  • 对于中、大型表，索引非常有效。
  • 对于特大型表，建立和使用索引的代价将随之增长。可以考虑使用分区技术。
  • 如果表的数量特别多，可以建立一个元数据信息表，用来查询需要用到的某些特性。

# 索引优化策略

  • 索引基本原则
    • 索引不是越多越好，不要为所有列都创建索引。
    • 要尽量避免冗余和重复索引。
    • 要考虑删除未使用的索引。
    • 尽量的扩展索引，不要新建索引。
    • 频繁作为 WHERE 过滤条件的列应该考虑添加索引。
  • 独立的列 - “独立的列” 是指索引列不能是表达式的一部分，也不能是函数的参数。
  • 前缀索引 - 索引很长的字符列，可以索引开始的部分字符，这样可以大大节约索引空间。
  • 最左匹配原则 - 将选择性高的列或基数大的列优先排在多列索引最前列。
  • 使用索引来排序 - 索引最好既满足排序，又用于查找行。这样，就可以使用索引来对结果排序。
  • =、IN 可以乱序 - 不需要考虑 =、IN 等的顺序
  • 覆盖索引
  • 自增字段作主键

# SQL 优化

使用 EXPLAIN 命令查看当前 SQL 是否使用了索引，优化后，再通过执行计划（EXPLAIN）来查看优化效果。

SQL 优化基本思路：

  • 只返回必要的列 - 最好不要使用 SELECT * 语句。

  • 只返回必要的行 - 使用 WHERE 子查询语句进行过滤查询，有时候也需要使用 LIMIT 语句来限制返回的数据。

  • 缓存重复查询的数据 - 应该考虑在客户端使用缓存，尽量不要使用 Mysql 服务器缓存（存在较多问题和限制）。

  • 使用索引来覆盖查询

# 优化 COUNT() 查询

COUNT() 有两种作用：

  • 统计某个列值的数量。统计列值时，要求列值是非 NULL 的，它不会统计 NULL。
  • 统计行数。

统计列值时，要求列值是非空的，它不会统计 NULL。如果确认括号中的表达式不可能为空时，实际上就是在统计行数。最简单的就是当使用 COUNT(*) 时，并不是我们所想象的那样扩展成所有的列，实际上，它会忽略所有的列而直接统计行数。

我们最常见的误解也就在这儿，在括号内指定了一列却希望统计结果是行数，而且还常常误以为前者的性能会更好。但实际并非这样，如果要统计行数，直接使用 COUNT(*)，意义清晰，且性能更好。

（1）简单优化

SELECT count(*) FROM world.city WHERE id > 5;
+
+SELECT (SELECT count(*) FROM world.city) - count(*)
+FROM world.city WHERE id <= 5;
+

（2）使用近似值

有时候某些业务场景并不需要完全精确的统计值，可以用近似值来代替，EXPLAIN 出来的行数就是一个不错的近似值，而且执行 EXPLAIN 并不需要真正地去执行查询，所以成本非常低。通常来说，执行 COUNT() 都需要扫描大量的行才能获取到精确的数据，因此很难优化，MySQL 层面还能做得也就只有覆盖索引了。如果不还能解决问题，只有从架构层面解决了，比如添加汇总表，或者使用 Redis 这样的外部缓存系统。

# 优化关联查询

在大数据场景下，表与表之间通过一个冗余字段来关联，要比直接使用 JOIN 有更好的性能。

如果确实需要使用关联查询的情况下，需要特别注意的是：

  • 确保 ON 和 USING 字句中的列上有索引。在创建索引的时候就要考虑到关联的顺序。当表 A 和表 B 用某列 column 关联的时候，如果优化器关联的顺序是 A、B，那么就不需要在 A 表的对应列上创建索引。没有用到的索引会带来额外的负担，一般来说，除非有其他理由，只需要在关联顺序中的第二张表的相应列上创建索引（具体原因下文分析）。
  • 确保任何的 GROUP BY 和 ORDER BY 中的表达式只涉及到一个表中的列，这样 MySQL 才有可能使用索引来优化。

要理解优化关联查询的第一个技巧，就需要理解 MySQL 是如何执行关联查询的。当前 MySQL 关联执行的策略非常简单，它对任何的关联都执行嵌套循环关联操作，即先在一个表中循环取出单条数据，然后在嵌套循环到下一个表中寻找匹配的行，依次下去，直到找到所有表中匹配的行为为止。然后根据各个表匹配的行，返回查询中需要的各个列。

太抽象了？以上面的示例来说明，比如有这样的一个查询：

SELECT A.xx,B.yy
+FROM A INNER JOIN B USING(c)
+WHERE A.xx IN (5,6)
+

假设 MySQL 按照查询中的关联顺序 A、B 来进行关联操作，那么可以用下面的伪代码表示 MySQL 如何完成这个查询：

outer_iterator = SELECT A.xx,A.c FROM A WHERE A.xx IN (5,6);
+outer_row = outer_iterator.next;
+while(outer_row) {
+    inner_iterator = SELECT B.yy FROM B WHERE B.c = outer_row.c;
+    inner_row = inner_iterator.next;
+    while(inner_row) {
+        output[inner_row.yy,outer_row.xx];
+        inner_row = inner_iterator.next;
+    }
+    outer_row = outer_iterator.next;
+}
+

可以看到，最外层的查询是根据A.xx列来查询的，A.c上如果有索引的话，整个关联查询也不会使用。再看内层的查询，很明显B.c上如果有索引的话，能够加速查询，因此只需要在关联顺序中的第二张表的相应列上创建索引即可。

# 优化 GROUP BY 和 DISTINCT

Mysql 优化器会在内部处理的时候相互转化这两类查询。它们都可以使用索引来优化，这也是最有效的优化方法。

# 优化 LIMIT

当需要分页操作时，通常会使用 LIMIT 加上偏移量的办法实现，同时加上合适的 ORDER BY 字句。如果有对应的索引，通常效率会不错，否则，MySQL 需要做大量的文件排序操作。

一个常见的问题是当偏移量非常大的时候，比如：LIMIT 10000 20这样的查询，MySQL 需要查询 10020 条记录然后只返回 20 条记录，前面的 10000 条都将被抛弃，这样的代价非常高。

优化这种查询一个最简单的办法就是尽可能的使用覆盖索引扫描，而不是查询所有的列。然后根据需要做一次关联查询再返回所有的列。对于偏移量很大时，这样做的效率会提升非常大。考虑下面的查询：

SELECT film_id,description FROM film ORDER BY title LIMIT 50,5;
+

如果这张表非常大，那么这个查询最好改成下面的样子：

SELECT film.film_id,film.description
+FROM film INNER JOIN (
+    SELECT film_id FROM film ORDER BY title LIMIT 50,5
+) AS tmp USING(film_id);
+

这里的延迟关联将大大提升查询效率，让 MySQL 扫描尽可能少的页面，获取需要访问的记录后在根据关联列回原表查询所需要的列。

有时候如果可以使用书签记录上次取数据的位置，那么下次就可以直接从该书签记录的位置开始扫描，这样就可以避免使用OFFSET，比如下面的查询：

SELECT id FROM t LIMIT 10000, 10;
+改为：
+SELECT id FROM t WHERE id > 10000 LIMIT 10;
+

其他优化的办法还包括使用预先计算的汇总表，或者关联到一个冗余表，冗余表中只包含主键列和需要做排序的列。

# 优化 UNION

MySQL 总是通过创建并填充临时表的方式来执行 UNION 查询。因此很多优化策略在UNION查询中都没有办法很好的时候。经常需要手动将WHERE、LIMIT、ORDER BY等字句“下推”到各个子查询中，以便优化器可以充分利用这些条件先优化。

除非确实需要服务器去重，否则就一定要使用UNION ALL，如果没有ALL关键字，MySQL 会给临时表加上DISTINCT选项，这会导致整个临时表的数据做唯一性检查，这样做的代价非常高。当然即使使用 ALL 关键字，MySQL 总是将结果放入临时表，然后再读出，再返回给客户端。虽然很多时候没有这个必要，比如有时候可以直接把每个子查询的结果返回给客户端。

# 优化查询方式

# 切分大查询

一个大查询如果一次性执行的话，可能一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。

DELEFT FROM messages WHERE create < DATE_SUB(NOW(), INTERVAL 3 MONTH);
+
rows_affected = 0
+do {
+    rows_affected = do_query(
+    "DELETE FROM messages WHERE create  < DATE_SUB(NOW(), INTERVAL 3 MONTH) LIMIT 10000")
+} while rows_affected > 0
+

# 分解大连接查询

将一个大连接查询（JOIN）分解成对每一个表进行一次单表查询，然后将结果在应用程序中进行关联，这样做的好处有：

  • 让缓存更高效。对于连接查询，如果其中一个表发生变化，那么整个查询缓存就无法使用。而分解后的多个查询，即使其中一个表发生变化，对其它表的查询缓存依然可以使用。
  • 分解成多个单表查询，这些单表查询的缓存结果更可能被其它查询使用到，从而减少冗余记录的查询。
  • 减少锁竞争；
  • 在应用层进行连接，可以更容易对数据库进行拆分，从而更容易做到高性能和可扩展。
  • 查询本身效率也可能会有所提升。例如下面的例子中，使用 IN() 代替连接查询，可以让 MySQL 按照 ID 顺序进行查询，这可能比随机的连接要更高效。
SELECT * FROM tag
+JOIN tag_post ON tag_post.tag_id=tag.id
+JOIN post ON tag_post.post_id=post.id
+WHERE tag.tag='mysql';
+
SELECT * FROM tag WHERE tag='mysql';
+SELECT * FROM tag_post WHERE tag_id=1234;
+SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);
+

# 执行计划（EXPLAIN）

如何判断当前 SQL 是否使用了索引？如何检验修改后的 SQL 确实有优化效果？

在 SQL 中，可以通过执行计划（EXPLAIN）分析 SELECT 查询效率。

mysql> explain select * from user_info where id = 2\G
+*************************** 1. row ***************************
+           id: 1
+  select_type: SIMPLE
+        table: user_info
+   partitions: NULL
+         type: const
+possible_keys: PRIMARY
+          key: PRIMARY
+      key_len: 8
+          ref: const
+         rows: 1
+     filtered: 100.00
+        Extra: NULL
+1 row in set, 1 warning (0.00 sec)
+

EXPLAIN 参数说明：

  • id: SELECT 查询的标识符. 每个 SELECT 都会自动分配一个唯一的标识符.
  • select_type ⭐ ：SELECT 查询的类型. +
    • SIMPLE：表示此查询不包含 UNION 查询或子查询
    • PRIMARY：表示此查询是最外层的查询
    • UNION：表示此查询是 UNION 的第二或随后的查询
    • DEPENDENT UNION：UNION 中的第二个或后面的查询语句, 取决于外面的查询
    • UNION RESULT：UNION 的结果
    • SUBQUERY：子查询中的第一个 SELECT
    • DEPENDENT SUBQUERY: 子查询中的第一个 SELECT, 取决于外面的查询. 即子查询依赖于外层查询的结果.
  • table: 查询的是哪个表，如果给表起别名了，则显示别名。
  • partitions：匹配的分区
  • type ⭐：表示从表中查询到行所执行的方式，查询方式是 SQL 优化中一个很重要的指标，结果值从好到差依次是：system > const > eq_ref > ref > range > index > ALL。 +
    • system/const：表中只有一行数据匹配，此时根据索引查询一次就能找到对应的数据。如果是 B + 树索引，我们知道此时索引构造成了多个层级的树，当查询的索引在树的底层时，查询效率就越低。const 表示此时索引在第一层，只需访问一层便能得到数据。
    • eq_ref：使用唯一索引扫描，常见于多表连接中使用主键和唯一索引作为关联条件。
    • ref：非唯一索引扫描，还可见于唯一索引最左原则匹配扫描。
    • range：索引范围扫描，比如，<，>，between 等操作。
    • index：索引全表扫描，此时遍历整个索引树。
    • ALL：表示全表扫描，需要遍历全表来找到对应的行。
  • possible_keys：此次查询中可能选用的索引。
  • key ⭐：此次查询中实际使用的索引。
  • ref：哪个字段或常数与 key 一起被使用。
  • rows ⭐：显示此查询一共扫描了多少行，这个是一个估计值。
  • filtered：表示此查询条件所过滤的数据的百分比。
  • extra：额外的信息。

更多内容请参考：MySQL 性能优化神器 Explain 使用分析 (opens new window)

# optimizer trace

在 MySQL 5.6 及之后的版本中，我们可以使用 optimizer trace 功能查看优化器生成执行计划的整个过程。有了这个功能，我们不仅可以了解优化器的选择过程，更可以了解每一个执行环节的成本，然后依靠这些信息进一步优化查询。

如下代码所示，打开 optimizer_trace 后，再执行 SQL 就可以查询 information_schema.OPTIMIZER_TRACE 表查看执行计划了，最后可以关闭 optimizer_trace 功能：

SET optimizer_trace="enabled=on";
+SELECT * FROM person WHERE NAME >'name84059' AND create_time>'2020-01-24 05:00
+SELECT * FROM information_schema.OPTIMIZER_TRACE;
+SET optimizer_trace="enabled=off";
+

# 数据模型和业务

  • 表字段比较复杂、易变动、结构难以统一的情况下，可以考虑使用 Nosql 来代替关系数据库表存储，如 ElasticSearch、MongoDB。
  • 在高并发情况下的查询操作，可以使用缓存（如 Redis）代替数据库操作，提高并发性能。
  • 数据量增长较快的表，需要考虑水平分表或分库，避免单表操作的性能瓶颈。
  • 除此之外，我们应该通过一些优化，尽量避免比较复杂的 JOIN 查询操作，例如冗余一些字段，减少 JOIN 查询；创建一些中间表，减少 JOIN 查询。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#Mysql#性能
上次更新: 2023/06/29, 22:27:04
Mysql 索引
Mysql 运维

+ ← + Mysql 运维→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/3c3c45/index.html b/pages/3c3c45/index.html new file mode 100644 index 00000000..063bdb11 --- /dev/null +++ b/pages/3c3c45/index.html @@ -0,0 +1,59 @@ + + + + + + 数据库综合 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-04-11
目录

数据库综合

# 数据库综合

# 📖 内容

# 📚 资料

# 🚪 传送

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#综合
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/417be6/index.html b/pages/417be6/index.html new file mode 100644 index 00000000..2186d078 --- /dev/null +++ b/pages/417be6/index.html @@ -0,0 +1,59 @@ + + + + + + HBase 教程 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-09
目录

HBase 教程

# HBase 教程

# 📖 内容

# 📚 资料

# 🚪 传送

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#大数据#HBase
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/451b73/index.html b/pages/451b73/index.html new file mode 100644 index 00000000..2aa6b560 --- /dev/null +++ b/pages/451b73/index.html @@ -0,0 +1,63 @@ + + + + + + Redis 面试总结 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-07-13
目录

Redis 面试总结

# Redis 面试总结

# Redis 数据类型

【问题】

  • Redis 有哪些数据类型？
  • Redis 的数据类型分别适用于什么样的场景？

【解答】

Redis 数据类型和应用

数据类型的特性和应用细节点较多，详情可以参考：Redis 数据类型 (opens new window)

（1）Redis 支持五种基本数据类型：

  • String：常用于 KV 缓存
  • Hash：存储结构化数据，如：产品信息、用户信息等。
  • List：存储列表，如：粉丝列表、文章评论列表等。可以通过 lrange 命令进行分页查询。
  • Set：存储去重列表，如：粉丝列表等。可以基于 set 玩儿交集、并集、差集的操作。例如：求两个人的共同好友列表。
  • Sorted Set：存储含评分的去重列表，如：各种排行榜。

（2）除此以外，还有 Bitmaps、HyperLogLogs、GEO、Streams 等高级数据类型。

# Redis 内存淘汰

【问题】

  • Redis 有哪些内存淘汰策略？
  • 这些淘汰策略分别适用于什么场景？
  • Redis 有哪些删除失效 key 的方法？
  • 如何设置 Redis 中键的过期时间？
  • 如果让你实现一个 LRU 算法，怎么做？

【解答】

（1）Redis 过期策略是：定期删除+惰性删除。

  • 消极方法（passive way），在主键被访问时如果发现它已经失效，那么就删除它。
  • 主动方法（active way），定期从设置了失效时间的主键中选择一部分失效的主键删除。

（2）Redis 内存淘汰策略：

  • noeviction - 当内存使用达到阈值的时候，所有引起申请内存的命令会报错。这是 Redis 默认的策略。
  • allkeys-lru - 在主键空间中，优先移除最近未使用的 key。
  • allkeys-random - 在主键空间中，随机移除某个 key。
  • volatile-lru - 在设置了过期时间的键空间中，优先移除最近未使用的 key。
  • volatile-random - 在设置了过期时间的键空间中，随机移除某个 key。
  • volatile-ttl - 在设置了过期时间的键空间中，具有更早过期时间的 key 优先移除。

（3）如何选择内存淘汰策略：

  • 如果数据呈现幂等分布，也就是一部分数据访问频率高，一部分数据访问频率低，则使用 allkeys-lru。
  • 如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用 allkeys-random。
  • volatile-lru 策略和 volatile-random 策略适合我们将一个 Redis 实例既应用于缓存和又应用于持久化存储的时候，然而我们也可以通过使用两个 Redis 实例来达到相同的效果。
  • 将 key 设置过期时间实际上会消耗更多的内存，因此我们建议使用 allkeys-lru 策略从而更有效率的使用内存。

（4）LRU 算法实现思路：可以继承 LinkedHashMap，并覆写 removeEldestEntry 方法来实现一个最简单的 LRUCache

# Redis 持久化

【问题】

  • Redis 有几种持久化方式？
  • Redis 的不同持久化方式的特性和原理是什么？
  • RDB 和 AOF 各有什么优缺点？分别适用于什么样的场景？
  • Redis 执行持久化时，可以处理请求吗？
  • AOF 有几种同步频率？

【解答】

Redis 持久化

详情可以参考：Redis 持久化

（1）Redis 支持两种持久化方式：RDB 和 AOF。

（2）RDB 即某一时刻的二进制数据快照。

Redis 会周期性生成 RDB 文件。

生成 RDB 流程：Redis fork 一个子进程，负责生成 RDB；生成 RDB 采用 Copy On Write 模式，此时，如果收到写请求，会在原副本上操作，不影响工作。

RDB 只能恢复生成快照时刻的数据，之后的数据无法恢复。生成 RDB 的资源开销高昂。RDB 适合做冷备。

（3）AOF 会将写命令不断追加到 AOF 文本日志末尾。

AOF 丢数据比 RDB 少，但文件会比 RDB 文件大很多。

一般，AOF 设置 appendfsync 同步频率为 everysec 即可。

（4）RDB or AOF

建议同时使用 RDB 和 AOF。用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。

# Redis 事务

【问题】

  • Redis 的并发竞争问题是什么？如何解决这个问题？
  • Redis 支持事务吗？
  • Redis 事务是严格意义的事务吗？Redis 为什么不支持回滚。
  • Redis 事务如何工作？
  • 了解 Redis 事务中的 CAS 行为吗？

【解答】

Redis 的事务特性、原理

详情参考：Redis 应用指南之 事务

Redis 提供的不是严格的事务，Redis 只保证串行执行命令，并且能保证全部执行，但是执行命令失败时并不会回滚，而是会继续执行下去。

Redis 不支持回滚的理由：

  • Redis 命令只会因为错误的语法而失败，或是命令用在了错误类型的键上面。
  • 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务相关的命令。

Redis 有天然解决这个并发竞争问题的类 CAS 乐观锁方案：每次要写之前，先判断一下当前这个 value 的时间戳是否比缓存里的 value 的时间戳要新。如果是的话，那么可以写，否则，就不能用旧的数据覆盖新的数据。

# Redis 管道

【问题】

  • 除了事务，还有其他批量执行 Redis 命令的方式吗？

【解答】

Redis 是一种基于 C/S 模型以及请求/响应协议的 TCP 服务。Redis 支持管道技术。管道技术允许请求以异步方式发送，即旧请求的应答还未返回的情况下，允许发送新请求。这种方式可以大大提高传输效率。使用管道发送命令时，Redis Server 会将部分请求放到缓存队列中（占用内存），执行完毕后一次性发送结果。如果需要发送大量的命令，会占用大量的内存，因此应该按照合理数量分批次的处理。

# Redis 高并发

【问题】

  • Redis 是单线程模型，为何吞吐量还很高？
  • Redis 的 IO 多路复用原理是什么？
  • Redis 集群如何分片和寻址？
  • Redis 集群如何扩展？
  • Redis 集群如何保证数据一致？
  • Redis 集群如何规划？你们公司的生产环境上如何部署 Redis 集群？

【解答】

Redis 集群

详情可以参考：Redis 集群

（1）单线程

Redis 为单进程单线程模式，采用队列模式将并发访问变为串行访问。Redis 单机吞吐量也很高，能达到几万 QPS。

Redis 单线程模型，依然有很高的并发吞吐，原因在于：

  • Redis 读写都是内存操作。
  • Redis 基于非阻塞的 IO 多路复用机制，同时监听多个 socket，将产生事件的 socket 压入内存队列中，事件分派器根据 socket 上的事件类型来选择对应的事件处理器进行处理。
  • 单线程，避免了线程创建、销毁、上下文切换的开销，并且避免了资源竞争。

（2）扩展并发吞吐量、存储容量

Redis 的高性能（扩展并发吞吐量、存储容量）通过主从架构来实现。

Redis 集群采用主从模型，提供复制和故障转移功能，来保证 Redis 集群的高可用。通常情况，一主多从模式已经可以满足大部分项目的需要。根据实际的并发量，可以通过增加节点来扩展并发吞吐。

一主多从模式下，主节点负责写操作（单机几万 QPS），从节点负责查询操作（单机十万 QPS）。

进一步，如果需要缓存大量数据，就需要分区（sharding）。Redis 集群通过划分虚拟 hash 槽来分片，每个主节点负责一定范围的 hash 槽。当需要扩展集群节点时，重新分配 hash 槽即可，redis-trib 会自动迁移变更 hash 槽中所属的 key。

（3）Redis 集群数据一致性

Redis 集群基于复制特性实现节点间的数据一致性。

# Redis 复制

【问题】

  • Redis 复制的工作原理？Redis 旧版复制和新版复制有何不同？
  • Redis 主从节点间如何复制数据？
  • Redis 的数据一致性是强一致性吗？

【解答】

Redis 复制

详情可以参考：Redis 复制

（1）旧版复制基于 SYNC 命令实现。分为同步（sync）和命令传播（command propagate）两个操作。这种方式存在缺陷：不能高效处理断线重连后的复制情况。

（2）新版复制基于 PSYNC 命令实现。同步操作分为了两块：

  • 完整重同步（full resychronization） 用于初次复制；
  • 部分重同步（partial resychronization） 用于断线后重复制。 +
    • 主从服务器的复制偏移量（replication offset）
    • 主服务器的复制积压缓冲区（replication backlog）
    • 服务器的运行 ID

（3）Redis 集群主从节点复制的工作流程：

  • 步骤 1. 设置主从服务器
  • 步骤 2. 主从服务器建立 TCP 连接。
  • 步骤 3. 发送 PING 检查通信状态。
  • 步骤 4. 身份验证。
  • 步骤 5. 发送端口信息。
  • 步骤 6. 同步。
  • 步骤 7. 命令传播。

# Redis 哨兵

【问题】

  • Redis 如何实现高可用？
  • Redis 哨兵的功能？
  • Redis 哨兵的原理？
  • Redis 哨兵如何选举 Leader？
  • Redis 如何实现故障转移？

【解答】

Redis 哨兵

详情可以参考：Redis 哨兵

（1）Redis 的高可用是通过哨兵来实现（Raft 协议的 Redis 实现）。Sentinel（哨兵）可以监听主服务器，并在主服务器进入下线状态时，自动从从服务器中选举出新的主服务器。

由一个或多个 Sentinel 实例组成的 Sentinel 系统可以监视任意多个主服务器，以及这些主服务器的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

img

# Redis vs. Memcached

【问题】

Redis 和 Memcached 有什么区别？

分布式缓存技术选型，选 Redis 还是 Memcached，为什么？

Redis 和 Memcached 各自的线程模型是怎样的？

为什么单线程的 Redis 性能却不输于多线程的 Memcached？

【解答】

Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。memcache 支持简单的数据类型，String。

Redis 支持数据的备份，即 master-slave 模式的数据备份。

Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用,而 Memecache 把数据全部存在内存之中

redis 的速度比 memcached 快很多

Memcached 是多线程，非阻塞 IO 复用的网络模型；Redis 使用单线程的 IO 复用模型。

Redis与Memcached的区别与比较

如果想要更详细了解的话，可以查看慕课网上的这篇手记（非常推荐） ：《脚踏两只船的困惑 - Memcached 与 Redis》：www.imooc.com/article/23549 (opens new window)

终极策略： 使用 Redis 的 String 类型做的事，都可以用 Memcached 替换，以此换取更好的性能提升； 除此以外，优先考虑 Redis；

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#KV数据库#Redis#面试
上次更新: 2023/06/29, 22:27:04
MongoDB 运维
Redis 应用指南

+ ← + Redis 应用指南→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/4574fe/index.html b/pages/4574fe/index.html new file mode 100644 index 00000000..036f28e6 --- /dev/null +++ b/pages/4574fe/index.html @@ -0,0 +1,69 @@ + + + + + + MongoDB 事务 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-20

MongoDB 事务

# MongoDB 事务

writeConcern 可以决定写操作到达多少个节点才算成功。

  • 默认：多节点复制集不做任何设定，所以是有可能丢失数据。
  • w: "majority"：大部分节点确认，就视为写成功
  • w: "all"：全部节点确认，才视为写成功

journal 则定义如何才算成功。取值包括：

  • true：写操作落到 journal 文件中才算成功；
  • false：写操作达到内存即算作成功。

【示例】在集群中使用 writeConcern 参数

db.transaction.insert({ count: 1 }, { writeConcern: { w: 'majoriy' } })
+db.transaction.insert({ count: 1 }, { writeConcern: { w: '4' } })
+db.transaction.insert({ count: 1 }, { writeConcern: { w: 'all' } })
+

【示例】配置延迟节点，模拟网络延迟

conf=rs.conf()
+conf.memebers[2].slaveDelay=5
+conf.memebers[2].priority=0
+rs.reconfig(conf)
+
+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#文档数据库#MongoDB#事务
上次更新: 2023/06/29, 22:27:04
MongoDB 的聚合操作
MongoDB 建模

+ ← + MongoDB 建模→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/4b1907/index.html b/pages/4b1907/index.html new file mode 100644 index 00000000..678127bb --- /dev/null +++ b/pages/4b1907/index.html @@ -0,0 +1,728 @@ + + + + + + Elasticsearch Rest API | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-16
目录

Elasticsearch Rest API

# ElasticSearch Rest API

Elasticsearch (opens new window) 是一个分布式、RESTful 风格的搜索和数据分析引擎，能够解决不断涌现出的各种用例。 作为 Elastic Stack 的核心，它集中存储您的数据，帮助您发现意料之中以及意料之外的情况。

Elasticsearch (opens new window) 基于搜索库 Lucene (opens new window) 开发。ElasticSearch 隐藏了 Lucene 的复杂性，提供了简单易用的 REST API / Java API 接口（另外还有其他语言的 API 接口）。

以下简称 ES。

REST API 最详尽的文档应该参考：ES 官方 REST API (opens new window)

# ElasticSearch Rest API 语法格式

向 Elasticsearch 发出的请求的组成部分与其它普通的 HTTP 请求是一样的：

curl -X<VERB> '<PROTOCOL>://<HOST>:<PORT>/<PATH>?<QUERY_STRING>' -d '<BODY>'
+
  • VERB：HTTP 方法，支持：GET, POST, PUT, HEAD, DELETE
  • PROTOCOL：http 或者 https 协议（只有在 Elasticsearch 前面有 https 代理的时候可用）
  • HOST：Elasticsearch 集群中的任何一个节点的主机名，如果是在本地的节点，那么就叫 localhost
  • PORT：Elasticsearch HTTP 服务所在的端口，默认为 9200 PATH API 路径（例如_count 将返回集群中文档的数量），
  • PATH：可以包含多个组件，例如 _cluster/stats 或者 _nodes/stats/jvm
  • QUERY_STRING：一些可选的查询请求参数，例如?pretty 参数将使请求返回更加美观易读的 JSON 数据
  • BODY：一个 JSON 格式的请求主体（如果请求需要的话）

ElasticSearch Rest API 分为两种：

  • URI Search：在 URL 中使用查询参数
  • Request Body Search：基于 JSON 格式的、更加完备的 DSL

URI Search 示例：

Request Body Search 示例：

# 索引 API

参考资料：Elasticsearch 官方之 cat 索引 API (opens new window)

# 创建索引

新建 Index，可以直接向 ES 服务器发出 PUT 请求。

语法格式：

PUT /my_index
+{
+    "settings": { ... any settings ... },
+    "mappings": {
+        "type_one": { ... any mappings ... },
+        "type_two": { ... any mappings ... },
+        ...
+    }
+}
+

示例：

PUT /user
+{
+  "settings": {
+    "index": {
+      "number_of_shards": 3,
+      "number_of_replicas": 2
+    }
+  }
+}
+

服务器返回一个 JSON 对象，里面的 acknowledged 字段表示操作成功。

{"acknowledged":true,"shards_acknowledged":true,"index":"user"}
+

如果你想禁止自动创建索引，可以通过在 config/elasticsearch.yml 的每个节点下添加下面的配置：

action.auto_create_index: false
+

# 删除索引

然后，我们可以通过发送 DELETE 请求，删除这个 Index。

DELETE /user
+

删除多个索引

DELETE /index_one,index_two
+DELETE /index_*
+

# 查看索引

可以通过 GET 请求查看索引信息

# 查看索引相关信息
+GET kibana_sample_data_ecommerce
+
+# 查看索引的文档总数
+GET kibana_sample_data_ecommerce/_count
+
+# 查看前10条文档，了解文档格式
+GET kibana_sample_data_ecommerce/_search
+
+# _cat indices API
+# 查看indices
+GET /_cat/indices/kibana*?v&s=index
+
+# 查看状态为绿的索引
+GET /_cat/indices?v&health=green
+
+# 按照文档个数排序
+GET /_cat/indices?v&s=docs.count:desc
+
+# 查看具体的字段
+GET /_cat/indices/kibana*?pri&v&h=health,index,pri,rep,docs.count,mt
+
+# 查看索引占用的内存
+GET /_cat/indices?v&h=i,tm&s=tm:desc
+

# 索引别名

ES 的索引别名就是给一个索引或者多个索引起的另一个名字，典型的应用场景是针对索引使用的平滑切换。

首先，创建索引 my_index，然后将别名 my_alias 指向它，示例如下：

PUT /my_index
+PUT /my_index/_alias/my_alias
+

也可以通过如下形式：

POST /_aliases
+{
+  "actions": [
+    { "add": { "index": "my_index", "alias": "my_alias" }}
+  ]
+}
+

也可以在一次请求中增加别名和移除别名混合使用：

POST /_aliases
+{
+  "actions": [
+    { "remove": { "index": "my_index", "alias": "my_alias" }}
+    { "add": { "index": "my_index_v2", "alias": "my_alias" }}
+  ]
+}
+

需要注意的是，如果别名与索引是一对一的，使用别名索引文档或者查询文档是可以的，但是如果别名和索引是一对多的，使用别名会发生错误，因为 ES 不知道把文档写入哪个索引中去或者从哪个索引中读取文档。

ES 索引别名有个典型的应用场景是平滑切换，更多细节可以查看 Elasticsearch（ES）索引零停机（无需重启）无缝平滑切换的方法 (opens new window)。

# 打开/关闭索引

通过在 POST 中添加 _close 或 _open 可以打开、关闭索引。

打开索引

# 打开索引
+POST kibana_sample_data_ecommerce/_open
+# 关闭索引
+POST kibana_sample_data_ecommerce/_close
+

# 文档

############Create Document############
+#create document. 自动生成 _id
+POST users/_doc
+{
+	"user" : "Mike",
+    "post_date" : "2019-04-15T14:12:12",
+    "message" : "trying out Kibana"
+}
+
+#create document. 指定Id。如果id已经存在，报错
+PUT users/_doc/1?op_type=create
+{
+    "user" : "Jack",
+    "post_date" : "2019-05-15T14:12:12",
+    "message" : "trying out Elasticsearch"
+}
+
+#create document. 指定 ID 如果已经存在，就报错
+PUT users/_create/1
+{
+     "user" : "Jack",
+    "post_date" : "2019-05-15T14:12:12",
+    "message" : "trying out Elasticsearch"
+}
+
+### Get Document by ID
+#Get the document by ID
+GET users/_doc/1
+
+
+###  Index & Update
+#Update 指定 ID  (先删除，在写入)
+GET users/_doc/1
+
+PUT users/_doc/1
+{
+	"user" : "Mike"
+
+}
+
+
+#GET users/_doc/1
+#在原文档上增加字段
+POST users/_update/1/
+{
+    "doc":{
+        "post_date" : "2019-05-15T14:12:12",
+        "message" : "trying out Elasticsearch"
+    }
+}
+
+
+
+### Delete by Id
+# 删除文档
+DELETE users/_doc/1
+
+
+### Bulk 操作
+#执行两次，查看每次的结果
+
+#执行第1次
+POST _bulk
+{ "index" : { "_index" : "test", "_id" : "1" } }
+{ "field1" : "value1" }
+{ "delete" : { "_index" : "test", "_id" : "2" } }
+{ "create" : { "_index" : "test2", "_id" : "3" } }
+{ "field1" : "value3" }
+{ "update" : {"_id" : "1", "_index" : "test"} }
+{ "doc" : {"field2" : "value2"} }
+
+
+#执行第2次
+POST _bulk
+{ "index" : { "_index" : "test", "_id" : "1" } }
+{ "field1" : "value1" }
+{ "delete" : { "_index" : "test", "_id" : "2" } }
+{ "create" : { "_index" : "test2", "_id" : "3" } }
+{ "field1" : "value3" }
+{ "update" : {"_id" : "1", "_index" : "test"} }
+{ "doc" : {"field2" : "value2"} }
+
+### mget 操作
+GET /_mget
+{
+    "docs" : [
+        {
+            "_index" : "test",
+            "_id" : "1"
+        },
+        {
+            "_index" : "test",
+            "_id" : "2"
+        }
+    ]
+}
+
+
+#URI中指定index
+GET /test/_mget
+{
+    "docs" : [
+        {
+
+            "_id" : "1"
+        },
+        {
+
+            "_id" : "2"
+        }
+    ]
+}
+
+
+GET /_mget
+{
+    "docs" : [
+        {
+            "_index" : "test",
+            "_id" : "1",
+            "_source" : false
+        },
+        {
+            "_index" : "test",
+            "_id" : "2",
+            "_source" : ["field3", "field4"]
+        },
+        {
+            "_index" : "test",
+            "_id" : "3",
+            "_source" : {
+                "include": ["user"],
+                "exclude": ["user.location"]
+            }
+        }
+    ]
+}
+
+### msearch 操作
+POST kibana_sample_data_ecommerce/_msearch
+{}
+{"query" : {"match_all" : {}},"size":1}
+{"index" : "kibana_sample_data_flights"}
+{"query" : {"match_all" : {}},"size":2}
+
+
+### 清除测试数据
+#清除数据
+DELETE users
+DELETE test
+DELETE test2
+

# 创建文档

# 指定 ID

语法格式：

PUT /_index/_type/_create/_id
+

示例：

PUT /user/_doc/_create/1
+{
+  "user": "张三",
+  "title": "工程师",
+  "desc": "数据库管理"
+}
+

注意：指定 Id，如果 id 已经存在，则报错

# 自动生成 ID

新增记录的时候，也可以不指定 Id，这时要改成 POST 请求。

语法格式：

POST /_index/_type
+

示例：

POST /user/_doc
+{
+  "user": "张三",
+  "title": "工程师",
+  "desc": "超级管理员"
+}
+

# 删除文档

语法格式：

DELETE /_index/_doc/_id
+

示例：

DELETE /user/_doc/1
+

# 更新文档

# 先删除，再写入

语法格式：

PUT /_index/_type/_id
+

示例：

PUT /user/_doc/1
+{
+  "user": "李四",
+  "title": "工程师",
+  "desc": "超级管理员"
+}
+

# 在原文档上增加字段

语法格式：

POST /_index/_update/_id
+

示例：

POST /user/_update/1
+{
+    "doc":{
+        "age" : "30"
+    }
+}
+

# 查询文档

# 指定 ID 查询

语法格式：

GET /_index/_type/_id
+

示例：

GET /user/_doc/1
+

结果：

{
+  "_index": "user",
+  "_type": "_doc",
+  "_id": "1",
+  "_version": 1,
+  "_seq_no": 536248,
+  "_primary_term": 2,
+  "found": true,
+  "_source": {
+    "user": "张三",
+    "title": "工程师",
+    "desc": "数据库管理"
+  }
+}
+

返回的数据中，found 字段表示查询成功，_source 字段返回原始记录。

如果 id 不正确，就查不到数据，found 字段就是 false

# 查询所有记录

使用 GET 方法，直接请求 /index/type/_search，就会返回所有记录。

$ curl 'localhost:9200/user/admin/_search?pretty'
+{
+  "took" : 1,
+  "timed_out" : false,
+  "_shards" : {
+    "total" : 3,
+    "successful" : 3,
+    "skipped" : 0,
+    "failed" : 0
+  },
+  "hits" : {
+    "total" : 2,
+    "max_score" : 1.0,
+    "hits" : [
+      {
+        "_index" : "user",
+        "_type" : "admin",
+        "_id" : "WWuoDG8BHwECs7SiYn93",
+        "_score" : 1.0,
+        "_source" : {
+          "user" : "李四",
+          "title" : "工程师",
+          "desc" : "系统管理"
+        }
+      },
+      {
+        "_index" : "user",
+        "_type" : "admin",
+        "_id" : "1",
+        "_score" : 1.0,
+        "_source" : {
+          "user" : "张三",
+          "title" : "工程师",
+          "desc" : "超级管理员"
+        }
+      }
+    ]
+  }
+}
+

上面代码中，返回结果的 took字段表示该操作的耗时（单位为毫秒），timed_out字段表示是否超时，hits字段表示命中的记录，里面子字段的含义如下。

  • total：返回记录数，本例是 2 条。
  • max_score：最高的匹配程度，本例是1.0。
  • hits：返回的记录组成的数组。

返回的记录中，每条记录都有一个_score字段，表示匹配的程序，默认是按照这个字段降序排列。

# 全文搜索

ES 的查询非常特别，使用自己的查询语法 (opens new window)，要求 GET 请求带有数据体。

$ curl -H 'Content-Type: application/json' 'localhost:9200/user/admin/_search?pretty'  -d '
+{
+"query" : { "match" : { "desc" : "管理" }}
+}'
+

上面代码使用 Match 查询 (opens new window)，指定的匹配条件是desc字段里面包含"软件"这个词。返回结果如下。

{
+  "took" : 2,
+  "timed_out" : false,
+  "_shards" : {
+    "total" : 3,
+    "successful" : 3,
+    "skipped" : 0,
+    "failed" : 0
+  },
+  "hits" : {
+    "total" : 2,
+    "max_score" : 0.38200712,
+    "hits" : [
+      {
+        "_index" : "user",
+        "_type" : "admin",
+        "_id" : "WWuoDG8BHwECs7SiYn93",
+        "_score" : 0.38200712,
+        "_source" : {
+          "user" : "李四",
+          "title" : "工程师",
+          "desc" : "系统管理"
+        }
+      },
+      {
+        "_index" : "user",
+        "_type" : "admin",
+        "_id" : "1",
+        "_score" : 0.3487891,
+        "_source" : {
+          "user" : "张三",
+          "title" : "工程师",
+          "desc" : "超级管理员"
+        }
+      }
+    ]
+  }
+}
+

Elastic 默认一次返回 10 条结果，可以通过size字段改变这个设置，还可以通过from字段，指定位移。

$ curl 'localhost:9200/user/admin/_search'  -d '
+{
+  "query" : { "match" : { "desc" : "管理" }},
+  "from": 1,
+  "size": 1
+}'
+

上面代码指定，从位置 1 开始（默认是从位置 0 开始），只返回一条结果。

# 逻辑运算

如果有多个搜索关键字， Elastic 认为它们是or关系。

$ curl 'localhost:9200/user/admin/_search'  -d '
+{
+"query" : { "match" : { "desc" : "软件 系统" }}
+}'
+

上面代码搜索的是软件 or 系统。

如果要执行多个关键词的and搜索，必须使用布尔查询 (opens new window)。

$ curl -H 'Content-Type: application/json' 'localhost:9200/user/admin/_search?pretty'  -d '
+{
+ "query": {
+  "bool": {
+   "must": [
+    { "match": { "desc": "管理" } },
+    { "match": { "desc": "超级" } }
+   ]
+  }
+ }
+}'
+

# 批量执行

支持在一次 API 调用中，对不同的索引进行操作

支持四种类型操作

  • index
  • create
  • update
  • delete

操作中单条操作失败，并不会影响其他操作。

返回结果包括了每一条操作执行的结果。

POST _bulk
+{ "index" : { "_index" : "test", "_id" : "1" } }
+{ "field1" : "value1" }
+{ "delete" : { "_index" : "test", "_id" : "2" } }
+{ "create" : { "_index" : "test2", "_id" : "3" } }
+{ "field1" : "value3" }
+{ "update" : {"_id" : "1", "_index" : "test"} }
+{ "doc" : {"field2" : "value2"} }
+

说明：上面的示例如果执行多次，执行结果都不一样。

# 批量读取

读多个索引

GET /_mget
+{
+    "docs" : [
+        {
+            "_index" : "test",
+            "_id" : "1"
+        },
+        {
+            "_index" : "test",
+            "_id" : "2"
+        }
+    ]
+}
+

读一个索引

GET /test/_mget
+{
+    "docs" : [
+        {
+
+            "_id" : "1"
+        },
+        {
+
+            "_id" : "2"
+        }
+    ]
+}
+
+GET /_mget
+{
+    "docs" : [
+        {
+            "_index" : "test",
+            "_id" : "1",
+            "_source" : false
+        },
+        {
+            "_index" : "test",
+            "_id" : "2",
+            "_source" : ["field3", "field4"]
+        },
+        {
+            "_index" : "test",
+            "_id" : "3",
+            "_source" : {
+                "include": ["user"],
+                "exclude": ["user.location"]
+            }
+        }
+    ]
+}
+

# 批量查询

POST kibana_sample_data_ecommerce/_msearch
+{}
+{"query" : {"match_all" : {}},"size":1}
+{"index" : "kibana_sample_data_flights"}
+{"query" : {"match_all" : {}},"size":2}
+

# URI Search 查询语义

Elasticsearch URI Search 遵循 QueryString 查询语义，其形式如下：

GET /movies/_search?q=2012&df=title&sort=year:desc&from=0&size=10&timeout=1s
+{
+	"profile": true
+}
+
  • q 指定查询语句，使用 QueryString 语义
  • df 默认字段，不指定时
  • sort 排序：from 和 size 用于分页
  • profile 可以查看查询时如何被执行的
GET /movies/_search?q=title:2012&sort=year:desc&from=0&size=10&timeout=1s
+{
+	"profile":"true"
+}
+

# Term 和 Phrase

Beautiful Mind 等效于 Beautiful OR Mind

"Beautiful Mind" 等效于 Beautiful AND Mind

# Term 查询
+GET /movies/_search?q=title:Beautiful Mind
+{
+	"profile":"true"
+}
+
+# 使用引号，Phrase 查询
+GET /movies/_search?q=title:"Beautiful Mind"
+{
+	"profile":"true"
+}
+

# 分组与引号

title:(Beautiful AND Mind)

title="Beautiful Mind"

# AND、OR、NOT 或者 &&、||、!

注意：AND、OR、NOT 必须大写

# 布尔操作符
+GET /movies/_search?q=title:(Beautiful AND Mind)
+{
+	"profile":"true"
+}
+
+GET /movies/_search?q=title:(Beautiful NOT Mind)
+{
+	"profile":"true"
+}
+

# 范围查询

  • [] 表示闭区间
  • {} 表示开区间

示例：

# 范围查询 ,区间写法
+GET /movies/_search?q=title:beautiful AND year:{2010 TO 2018%7D
+{
+	"profile":"true"
+}
+
+GET /movies/_search?q=title:beautiful AND year:[* TO 2018]
+{
+	"profile":"true"
+}
+

# 算数符号

# 2010 年以后的记录
+GET /movies/_search?q=year:>2010
+{
+	"profile":"true"
+}
+
+# 2010 年到 2018 年的记录
+GET /movies/_search?q=year:(>2010 && <=2018)
+{
+	"profile":"true"
+}
+
+# 2010 年到 2018 年的记录
+GET /movies/_search?q=year:(+>2010 +<=2018)
+{
+	"profile":"true"
+}
+

# 通配符查询

  • ? 代表 1 个字符
  • * 代表 0 或多个字符

示例：

GET /movies/_search?q=title:mi?d
+{
+	"profile":"true"
+}
+
+GET /movies/_search?q=title:b*
+{
+	"profile":"true"
+}
+

# 正则表达式

title:[bt]oy

# 模糊匹配与近似查询

示例：

# 相似度在 1 个字符以内
+GET /movies/_search?q=title:beautifl~1
+{
+	"profile":"true"
+}
+
+# 相似度在 2 个字符以内
+GET /movies/_search?q=title:"Lord Rings"~2
+{
+	"profile":"true"
+}
+

# Request Body & DSL

Elasticsearch 除了 URI Search 查询方式，还支持将查询语句通过 Http Request Body 发起查询。

GET /kibana_sample_data_ecommerce/_search?ignore_unavailable=true
+{
+	"profile":"true",
+	"query": {
+	  "match_all": {}
+	}
+}
+

# 分页

GET /kibana_sample_data_ecommerce/_search?ignore_unavailable=true
+{
+  "profile": "true",
+  "from": 0,
+  "size": 10,
+  "query": {
+    "match_all": {}
+  }
+}
+

# 排序

最好在数字型或日期型字段上排序

因为对于多值类型或分析过的字段排序，系统会选一个值，无法得知该值

GET /kibana_sample_data_ecommerce/_search?ignore_unavailable=true
+{
+  "profile": "true",
+  "sort": [
+    {
+      "order_date": "desc"
+    }
+  ],
+  "from": 1,
+  "size": 10,
+  "query": {
+    "match_all": {}
+  }
+}
+

# _source 过滤

如果 _source 没有存储，那就只返回匹配的文档的元数据

_source 支持使用通配符，如：_source["name*", "desc*"]

示例：

GET /kibana_sample_data_ecommerce/_search?ignore_unavailable=true
+{
+  "profile": "true",
+  "_source": [
+    "order_date",
+    "category.keyword"
+  ],
+  "from": 1,
+  "size": 10,
+  "query": {
+    "match_all": {}
+  }
+}
+

# 脚本字段

GET /kibana_sample_data_ecommerce/_search?ignore_unavailable=true
+{
+  "profile": "true",
+  "script_fields": {
+    "new_field": {
+      "script": {
+        "lang": "painless",
+        "source":"doc['order_date'].value+' hello'"
+      }
+    }
+  },
+  "from": 1,
+  "size": 10,
+  "query": {
+    "match_all": {}
+  }
+}
+
+

# 使用查询表达式 - Match

POST movies/_search
+{
+  "query": {
+    "match": {
+      "title": "last christmas"
+    }
+  }
+}
+
+POST movies/_search
+{
+  "query": {
+    "match": {
+      "title": {
+        "query": "last christmas",
+        "operator": "and"
+      }
+    }
+  }
+}
+
+

# 短语搜索 - Match Phrase

POST movies/_search
+{
+  "query": {
+    "match_phrase": {
+      "title":{
+        "query": "last christmas"
+
+      }
+    }
+  }
+}
+

# 集群 API

Elasticsearch 官方之 Cluster API (opens new window)

一些集群级别的 API 可能会在节点的子集上运行，这些节点可以用节点过滤器指定。例如，任务管理、节点统计和节点信息 API 都可以报告来自一组过滤节点而不是所有节点的结果。

节点过滤器以逗号分隔的单个过滤器列表的形式编写，每个过滤器从所选子集中添加或删除节点。每个过滤器可以是以下之一：

  • _all：将所有节点添加到子集
  • _local：将本地节点添加到子集
  • _master：将当前主节点添加到子集
  • 根据节点 ID 或节点名将匹配节点添加到子集
  • 根据 IP 地址或主机名将匹配节点添加到子集
  • 使用通配符，将节点名、地址名或主机名匹配的节点添加到子集
  • master:true, data:true, ingest:true, voting_only:true, ml:true 或 coordinating_only:true, 分别意味着将所有主节点、所有数据节点、所有摄取节点、所有仅投票节点、所有机器学习节点和所有协调节点添加到子集中。
  • master:false, data:false, ingest:false, voting_only:true, ml:false 或 coordinating_only:false, 分别意味着将所有主节点、所有数据节点、所有摄取节点、所有仅投票节点、所有机器学习节点和所有协调节点排除在子集外。
  • 配对模式，使用 * 通配符，格式为 attrname:attrvalue，将所有具有自定义节点属性的节点添加到子集中，其名称和值与相应的模式匹配。自定义节点属性是通过 node.attr.attrname: attrvalue 形式在配置文件中设置的。
# 如果没有给出过滤器，默认是查询所有节点
+GET /_nodes
+# 查询所有节点
+GET /_nodes/_all
+# 查询本地节点
+GET /_nodes/_local
+# 查询主节点
+GET /_nodes/_master
+# 根据名称查询节点（支持通配符）
+GET /_nodes/node_name_goes_here
+GET /_nodes/node_name_goes_*
+# 根据地址查询节点（支持通配符）
+GET /_nodes/10.0.0.3,10.0.0.4
+GET /_nodes/10.0.0.*
+# 根据规则查询节点
+GET /_nodes/_all,master:false
+GET /_nodes/data:true,ingest:true
+GET /_nodes/coordinating_only:true
+GET /_nodes/master:true,voting_only:false
+# 根据自定义属性查询节点（如：查询配置文件中含 node.attr.rack:2 属性的节点）
+GET /_nodes/rack:2
+GET /_nodes/ra*:2
+GET /_nodes/ra*:2*
+

# 集群健康 API

GET /_cluster/health
+GET /_cluster/health?level=shards
+GET /_cluster/health/kibana_sample_data_ecommerce,kibana_sample_data_flights
+GET /_cluster/health/kibana_sample_data_flights?level=shards
+

# 集群状态 API

集群状态 API 返回表示整个集群状态的元数据。

GET /_cluster/state
+

# 节点 API

Elasticsearch 官方之 cat Nodes API (opens new window)——返回有关集群节点的信息。

# 查看默认的字段
+GET /_cat/nodes?v=true
+# 查看指定的字段
+GET /_cat/nodes?v=true&h=id,ip,port,v,m
+

# 分片 API

Elasticsearch 官方之 cat Shards API (opens new window)——shards 命令是哪些节点包含哪些分片的详细视图。它会告诉你它是主还是副本、文档数量、它在磁盘上占用的字节数以及它所在的节点。

# 查看默认的字段
+GET /_cat/shards
+# 根据名称查询分片（支持通配符）
+GET /_cat/shards/my-index-*
+# 查看指定的字段
+GET /_cat/shards?h=index,shard,prirep,state,unassigned.reason
+

# 监控 API

Elasticsearch 中集群相关的健康、统计等相关的信息都是围绕着 cat API 进行的。

通过 GET 请求发送 cat，下面列出了所有可用的 API：

GET /_cat
+
+=^.^=
+/_cat/allocation
+/_cat/shards
+/_cat/shards/{index}
+/_cat/master
+/_cat/nodes
+/_cat/tasks
+/_cat/indices
+/_cat/indices/{index}
+/_cat/segments
+/_cat/segments/{index}
+/_cat/count
+/_cat/count/{index}
+/_cat/recovery
+/_cat/recovery/{index}
+/_cat/health
+/_cat/pending_tasks
+/_cat/aliases
+/_cat/aliases/{alias}
+/_cat/thread_pool
+/_cat/thread_pool/{thread_pools}
+/_cat/plugins
+/_cat/fielddata
+/_cat/fielddata/{fields}
+/_cat/nodeattrs
+/_cat/repositories
+/_cat/snapshots/{repository}
+/_cat/templates
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#API
上次更新: 2023/06/29, 22:27:04
Elasticsearch 性能优化
ElasticSearch Java API 之 High Level REST Client

+ ← + ElasticSearch Java API 之 High Level REST Client→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/4de901/index.html b/pages/4de901/index.html new file mode 100644 index 00000000..37971711 --- /dev/null +++ b/pages/4de901/index.html @@ -0,0 +1,81 @@ + + + + + + Redis 持久化 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-24
目录

Redis 持久化

# Redis 持久化

Redis 支持持久化，即把数据存储到硬盘中。

Redis 提供了两种持久化方式：

  • RDB 快照（snapshot） - 将存在于某一时刻的所有数据都写入到硬盘中。
  • 只追加文件（append-only file，AOF） - 它会在执行写命令时，将被执行的写命令复制到硬盘中。

这两种持久化方式既可以同时使用，也可以单独使用。

将内存中的数据存储到硬盘的一个主要原因是为了在之后重用数据，或者是为了防止系统故障而将数据备份到一个远程位置。另外，存储在 Redis 里面的数据有可能是经过长时间计算得出的，或者有程序正在使用 Redis 存储的数据进行计算，所以用户会希望自己可以将这些数据存储起来以便之后使用，这样就不必重新计算了。

Redis 提供了两种持久方式：RDB 和 AOF。你可以同时开启两种持久化方式。在这种情况下, 当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。

# 一、RDB

# RDB 简介

RDB 即快照方式，它将某个时间点的所有 Redis 数据保存到一个经过压缩的二进制文件（RDB 文件）中。

创建 RDB 后，用户可以对 RDB 进行备份，可以将 RDB 复制到其他服务器从而创建具有相同数据的服务器副本，还可以在重启服务器时使用。一句话来说：RDB 适合作为 冷备。

RDB 既可以手动执行，也可以根据服务器配置选项定期执行。该功能可以将某个时间点的数据库状态保存到一个 RDB 文件中。

# RDB 的优点

  • RDB 文件非常紧凑，适合作为冷备。比如你可以在每个小时报保存一下过去 24 小时内的数据，同时每天保存过去 30 天的数据，这样即使出了问题你也可以根据需求恢复到不同版本的数据集。
  • 快照在保存 RDB 文件时父进程唯一需要做的就是 fork 出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他 IO 操作，所以快照持久化方式可以最大化 Redis 的性能。
  • 恢复大数据集时，RDB 比 AOF 更快。

# RDB 的缺点

  • 如果系统发生故障，将会丢失最后一次创建快照之后的数据。如果你希望在 Redis 意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么 快照不适合你。虽然你可以配置不同的 save 时间点(例如每隔 5 分钟并且对数据集有 100 个写的操作)，是 Redis 要完整的保存整个数据集是一个比较繁重的工作，你通常会每隔 5 分钟或者更久做一次完整的保存，万一在 Redis 意外宕机，你可能会丢失几分钟的数据。
  • 如果数据量很大，保存快照的时间会很长。快照需要经常 fork 子进程来保存数据集到硬盘上。当数据集比较大的时候，fork 的过程是非常耗时的，可能会导致 Redis 在一些毫秒级内不能响应客户端的请求。如果数据集巨大并且 CPU 性能不是很好的情况下，这种情况会持续 1 秒。AOF 也需要 fork，但是你可以调节重写日志文件的频率来提高数据集的耐久度。

# RDB 的创建

有两个 Redis 命令可以用于生成 RDB 文件：SAVE 和 BGSAVE。

  • SAVE (opens new window) 命令会阻塞 Redis 服务器进程，直到 RDB 创建完成为止，在阻塞期间，服务器不能响应任何命令请求。
  • BGSAVE (opens new window) 命令会派生出（fork）一个子进程，然后由子进程负责创建 RDB 文件，服务器进程（父进程）继续处理命令请求。

🔔 注意：BGSAVE 命令执行期间，SAVE、BGSAVE、BGREWRITEAOF 三个命令会被拒绝，以免与当前的 BGSAVE 操作产生竞态条件，降低性能。

# 自动间隔保存

Redis 允许用户通过设置服务器配置的 save 选项，让服务器每隔一段时间自动执行一次 BGSAVE 命令。

用户可以通过 save 选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行 BGSAVE 命令。

举例来说，redis.conf 中设置了如下配置：

save 900 1       -- 900 秒内，至少对数据库进行了 1 次修改
+save 300 10      -- 300 秒内，至少对数据库进行了 10 次修改
+save 60 10000    -- 60 秒内，至少对数据库进行了 10000 次修改
+

只要满足以上任意条件，Redis 服务就会执行 BGSAVE 命令。

# RDB 的载入

RDB 文件的载入工作是在服务器启动时自动执行的，Redis 并没有专门用于载入 RDB 文件的命令。

服务器载入 RDB 文件期间，会一直处于阻塞状态，直到载入完成为止。

🔔 注意：因为 AOF 通常更新频率比 RDB 高，所以丢失数据相对更少。基于这个原因，Redis 有以下默认行为：

  • 只有在关闭 AOF 功能的情况下，才会使用 RDB 还原数据，否则优先使用 AOF 文件来还原数据。

# RDB 的文件结构

RDB 文件是一个经过压缩的二进制文件，由多个部分组成。

对于不同类型（STRING、HASH、LIST、SET、SORTED SET）的键值对，RDB 文件会使用不同的方式来保存它们。

img

Redis 本身提供了一个 RDB 文件检查工具 redis-check-dump。

# RDB 的配置

Redis RDB 默认配置如下：

save 900 1
+save 300 10
+save 60 10000
+stop-writes-on-bgsave-error yes
+rdbcompression yes
+rdbchecksum yes
+dbfilename dump.rdb
+dir ./
+

Redis 的配置文件 redis.conf 中与 RDB 有关的选项：

  • save - Redis 会根据 save 选项，让服务器每隔一段时间自动执行一次 BGSAVE 命令。

  • stop-writes-on-bgsave-error - 当 BGSAVE 命令出现错误时停止写 RDB 文件

  • rdbcompression - RDB 文件开启压缩功能。

  • rdbchecksum - 对 RDB 文件进行校验。

  • dbfilename - RDB 文件名。

  • dir - RDB 文件和 AOF 文件的存储路径。

# 二、AOF

# AOF 简介

AOF(Append Only File) 是以 文本日志形式 将 所有写命令以 Redis 命令请求协议格式追加到 AOF 文件的末尾，以此来记录数据的变化。当服务器重启时，会重新载入和执行 AOF 文件中的命令，就可以恢复原始的数据。AOF 适合作为 热备。

AOF 可以通过 appendonly yes 配置选项来开启。

命令请求会先保存到 AOF 缓冲区中，之后再定期写入并同步到 AOF 文件。

# AOF 的优点

  • 如果系统发生故障，AOF 丢失数据比 RDB 少。你可以使用不同的 fsync 策略：无 fsync；每秒 fsync；每次写的时候 fsync。使用默认的每秒 fsync 策略，Redis 的性能依然很好(fsync 是由后台线程进行处理的,主线程会尽力处理客户端请求)，一旦出现故障，你最多丢失 1 秒的数据。
  • AOF 文件可修复 - AOF 文件是一个只进行追加的日志文件，所以不需要写入 seek，即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令，你也也可使用 redis-check-aof 工具修复这些问题。
  • AOF 文件可压缩。Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
  • AOF 文件可读 - AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 命令的格式保存。因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单。举个例子，如果你不小心执行了 FLUSHALL 命令，但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis ，就可以将数据集恢复到 FLUSHALL 执行之前的状态。

# AOF 的缺点

  • AOF 文件体积一般比 RDB 大 - 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
  • 恢复大数据集时，AOF 比 RDB 慢。 - 根据所使用的 fsync 策略，AOF 的速度可能会慢于快照。在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和快照一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，快照可以提供更有保证的最大延迟时间（latency）。

# AOF 的创建

Redis 命令请求会先保存到 AOF 缓冲区，再定期写入并同步到 AOF 文件。

AOF 的实现可以分为命令追加（append）、文件写入、文件同步（sync）三个步骤。

  • 命令追加 - 当 Redis 服务器开启 AOF 功能时，服务器在执行完一个写命令后，会以 Redis 命令协议格式将被执行的写命令追加到 AOF 缓冲区的末尾。
  • 文件写入和文件同步 - Redis 的服务器进程就是一个事件循环，这个循环中的文件事件负责接收客户端的命令请求，以及向客户端发送命令回复。而时间事件则负责执行定时运行的函数。因为服务器在处理文件事件时可能会执行写命令，这些写命令会被追加到 AOF 缓冲区，服务器每次结束事件循环前，都会根据 appendfsync 选项来判断 AOF 缓冲区内容是否需要写入和同步到 AOF 文件中。

appendfsync 不同选项决定了不同的持久化行为：

  • always - 将缓冲区所有内容写入并同步到 AOF 文件。
  • everysec - 将缓冲区所有内容写入到 AOF 文件，如果上次同步 AOF 文件的时间距离现在超过一秒钟，那么再次对 AOF 文件进行同步，这个同步操作是有一个线程专门负责执行的。
  • no - 将缓冲区所有内容写入到 AOF 文件，但并不对 AOF 文件进行同步，何时同步由操作系统决定。

# AOF 的载入

因为 AOF 文件中包含了重建数据库所需的所有写命令，所以服务器只要载入并执行一遍 AOF 文件中保存的写命令，就可以还原服务器关闭前的数据库状态。

AOF 载入过程如下：

  1. 服务器启动载入程序。
  2. 创建一个伪客户端。因为 Redis 命令只能在客户端上下文中执行，所以需要创建一个伪客户端来载入、执行 AOF 文件中记录的命令。
  3. 从 AOF 文件中分析并读取一条写命令。
  4. 使用伪客户端执行写命令。
  5. 循环执行步骤 3、4，直到所有写命令都被处理完毕为止。
  6. 载入完毕。

# AOF 的重写

随着 Redis 不断运行，AOF 的体积也会不断增长，这将导致两个问题：

  • AOF 耗尽磁盘可用空间。
  • Redis 重启后需要执行 AOF 文件记录的所有写命令来还原数据集，如果 AOF 过大，则还原操作执行的时间就会非常长。

为了解决 AOF 体积膨胀问题，Redis 提供了 AOF 重写功能，来对 AOF 文件进行压缩。AOF 重写可以产生一个新的 AOF 文件，这个新的 AOF 文件和原来的 AOF 文件所保存的数据库状态一致，但体积更小。

AOF 重写并非读取和分析现有 AOF 文件的内容，而是直接从数据库中读取当前的数据库状态。即依次读取数据库中的每个键值对，然后用一条命令去记录该键值对，以此代替之前可能存在冗余的命令。

# AOF 后台重写

作为一种辅助性功能，显然 Redis 并不想在 AOF 重写时阻塞 Redis 服务接收其他命令。因此，Redis 决定通过 BGREWRITEAOF 命令创建一个子进程，然后由子进程负责对 AOF 文件进行重写，这与 BGSAVE 原理类似。

  • 在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区。当 AOF 重写子进程开始工作后，Redis 每执行完一个写命令，会同时将这个命令发送给 AOF 缓冲区和 AOF 重写缓冲区。
  • 由于彼此不是在同一个进程中工作，AOF 重写不影响 AOF 写入和同步。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾，使得新旧两个 AOF 文件所保存的数据库状态一致。
  • 最后，服务器用新的 AOF 文件替换就的 AOF 文件，以此来完成 AOF 重写操作。

img

可以通过设置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size，使得 Redis 在满足条件时，自动执行 BGREWRITEAOF。

假设配置如下：

auto-aof-rewrite-percentage 100
+auto-aof-rewrite-min-size 64mb
+

表明，当 AOF 大于 64MB，且 AOF 体积比上一次重写后的体积大了至少 100% 时，执行 BGREWRITEAOF。

# AOF 的配置

AOF 的默认配置：

appendonly no
+appendfsync everysec
+no-appendfsync-on-rewrite no
+auto-aof-rewrite-percentage 100
+auto-aof-rewrite-min-size 64mb
+

AOF 持久化通过在 redis.conf 中的 appendonly yes 配置选项来开启。

  • appendonly - 开启 AOF 功能。
  • appendfilename - AOF 文件名。
  • appendfsync - 用于设置同步频率，它有以下可选项： +
    • always - 每个 Redis 写命令都要同步写入硬盘。这样做会严重降低 Redis 的速度。
    • everysec - 每秒执行一次同步，显示地将多个写命令同步到硬盘。为了兼顾数据安全和写入性能，推荐使用 appendfsync everysec 选项。Redis 每秒同步一次 AOF 文件时的性能和不使用任何持久化特性时的性能相差无几。
    • no - 让操作系统来决定应该何时进行同步。
  • no-appendfsync-on-rewrite - AOF 重写时不支持追加命令。
  • auto-aof-rewrite-percentage - AOF 重写百分比。
  • auto-aof-rewrite-min-size - AOF 重写文件的最小大小。
  • dir - RDB 文件和 AOF 文件的存储路径。

# 三、RDB 和 AOF

当 Redis 启动时， 如果 RDB 和 AOF 功能都开启了，那么程序会优先使用 AOF 文件来恢复数据集，因为 AOF 文件所保存的数据通常是最完整的。

# 如何选择持久化

  • 如果不关心数据丢失，可以不持久化。
  • 如果可以承受数分钟以内的数据丢失，可以只使用 RDB。
  • 如果不能承受数分钟以内的数据丢失，可以同时使用 RDB 和 AOF。

有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且快照恢复数据集的速度也要比 AOF 恢复的速度要快，除此之外，使用快照还可以避免之前提到的 AOF 程序的 bug 。

# RDB 切换为 AOF

在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换为 AOF ：

  • 为最新的 dump.rdb 文件创建一个备份。
  • 将备份放到一个安全的地方。
  • 执行以下两条命令:
  • redis-cli config set appendonly yes
  • redis-cli config set save
  • 确保写命令会被正确地追加到 AOF 文件的末尾。
  • 执行的第一条命令开启了 AOF 功能： Redis 会阻塞直到初始 AOF 文件创建完成为止， 之后 Redis 会继续处理命令请求， 并开始将写入命令追加到 AOF 文件末尾。

执行的第二条命令用于关闭快照功能。 这一步是可选的， 如果你愿意的话， 也可以同时使用快照和 AOF 这两种持久化功能。

🔔 重要：别忘了在 redis.conf 中打开 AOF 功能！否则的话，服务器重启之后，之前通过 CONFIG SET 设置的配置就会被遗忘，程序会按原来的配置来启动服务器。

# AOF 和 RDB 的相互作用

BGSAVE 和 BGREWRITEAOF 命令不可以同时执行。这是为了避免两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。

如果 BGSAVE 正在执行，并且用户显示地调用 BGREWRITEAOF 命令，那么服务器将向用户回复一个 OK 状态，并告知用户，BGREWRITEAOF 已经被预定执行。一旦 BGSAVE 执行完毕， BGREWRITEAOF 就会正式开始。

# 四、Redis 备份

应该确保 Redis 数据有完整的备份。

备份 Redis 数据建议采用 RDB。

# 备份过程

  1. 创建一个定期任务（cron job），每小时将一个 RDB 文件备份到一个文件夹，并且每天将一个 RDB 文件备份到另一个文件夹。
  2. 确保快照的备份都带有相应的日期和时间信息，每次执行定期任务脚本时，使用 find 命令来删除过期的快照：比如说，你可以保留最近 48 小时内的每小时快照，还可以保留最近一两个月的每日快照。
  3. 至少每天一次，将 RDB 备份到你的数据中心之外，或者至少是备份到你运行 Redis 服务器的物理机器之外。

# 容灾备份

Redis 的容灾备份基本上就是对数据进行备份，并将这些备份传送到多个不同的外部数据中心。

容灾备份可以在 Redis 运行并产生快照的主数据中心发生严重的问题时，仍然让数据处于安全状态。

# 五、要点总结

img

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#KV数据库#Redis#持久化
上次更新: 2023/06/29, 22:27:04
Redis 数据类型和应用
Redis 复制

+ ← + Redis 复制→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/505407/index.html b/pages/505407/index.html new file mode 100644 index 00000000..7ebf1af8 --- /dev/null +++ b/pages/505407/index.html @@ -0,0 +1,62 @@ + + + + + + MongoDB 复制 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-20
目录

MongoDB 复制

# MongoDB 复制

# 副本和可用性

副本可以提供冗余并提高数据可用性。在不同数据库服务器上使用多个数据副本，可以提供一定程度的容错能力，以防止单个数据库服务器宕机时，数据丢失。

在某些情况下，副本还可以提供更大的读取吞吐量。因为客户端可以将读取操作发送到不同的服务器。在不同数据中心中维护数据副本可以提高数据本地性和分布式应用程序的可用性。您还可以维护其他副本以用于专用目的：例如灾难恢复，报告或备份。

# MongoDB 副本

MongoDB 中的副本集是一组维护相同数据集的 mongod 进程。一个副本集包含多个数据承载节点和一个仲裁器节点（可选）。在数据承载节点中，只有一个成员被视为主要节点，而其他节点则被视为次要节点。

主节点负责接收所有写操作。副本集只能有一个主副本，能够以 { w: "majority" } (opens new window) 来确认集群中节点的写操作成功情况；尽管在某些情况下，另一个 MongoDB 实例可能会暂时认为自己也是主要的。主节点在其操作日志（即 oplog (opens new window)）中记录了对其数据集的所有更改。

img

从节点复制主节点的操作日志，并将操作应用于其数据集，以便同步主节点的数据。如果主节点不可用，则符合条件的从节点将选举新的主节点。

img

在某些情况下（例如，有一个主节点和一个从节点，但由于成本限制，禁止添加另一个从节点），您可以选择将 mongod 实例作为仲裁节点添加到副本集。仲裁节点参加选举但不保存数据（即不提供数据冗余）。

img

仲裁节点将永远是仲裁节点。在选举期间，主节点可能会降级成为次节点，而次节点可能会升级成为主节点。

# 异步复制

# 慢操作

从节点复制主节点的操作日志，并将操作异步应用于其数据集。通过从节点同步主节点的数据集，即使一个或多个成员失败，副本集（MongoDB 集群）也可以继续运行。

从 4.2 版本开始，副本集的从节点记录慢操作（操作时间比设置的阈值长）的日志条目。这些慢操作在 REPL (opens new window) 组件下的 诊断日志 (opens new window) 中记录了日志消息，并使用了文本 op: <oplog entry> 花费了 <num>ms。这些慢操作日志条目仅取决于慢操作阈值，而不取决于日志级别（在系统级别或组件级别），配置级别或运行缓慢的采样率。探查器不会捕获缓慢的操作日志条目。

# 复制延迟和流控

复制延迟（Replication lag (opens new window)）是指将主节点上的写操作复制到从节点上所花费的时间。较短的延迟时间是可以接受的，但是随着复制延迟的增加，可能会出现严重的问题：比如在主节点上的缓存压力。

从 MongoDB 4.2 开始，管理员可以限制主节点的写入速率，使得大多数延迟时间保持在可配置的最大值 flowControlTargetLagSeconds (opens new window) 以下。

默认情况下，流控是开启的。

启用流控后，随着延迟时间越来越接近 flowControlTargetLagSeconds (opens new window)，主对象上的写操作必须先获得令牌，然后才能进行锁定并执行写操作。通过限制每秒发出的令牌数量，流控机制尝试将延迟保持在目标以下。

# 故障转移

当主节点与集群中的其他成员通信的时间超过配置的 electionTimeoutMillis（默认为 10 秒）时，符合选举要求的从节点将要求选举，并提名自己为新的主节点。集群尝试完成选举新主节点并恢复正常工作。

img

选举完成前，副本集无法处理写入操作。如果将副本集配置为：在主节点处于脱机状态时，在次节点上运行，则副本集可以继续提供读取查询。

假设副本配置 (opens new window)采用默认配置，则集群选择新节点的时间通常不应超过 12 秒，这包括：将主节点标记为不可用并完成选举所需的时间。可以通过修改 settings.electionTimeoutMillis (opens new window) 配置选项来调整此时间。网络延迟等因素可能会延长完成选举所需的时间，进而影响集群在没有主节点的情况下可以运行的时间。这些因素取决于集群实际的情况。

将默认为 10 秒的 electionTimeoutMillis (opens new window) 选项数值缩小，可以更快地检测到主要故障。但是，由于网络延迟等因素，集群可能会更频繁地进行选举，即使该主节点实际上处于健康状态。这可能导致 w : 1 (opens new window) 写操作的回滚次数增加。

应用程序的连接逻辑应包括对自动故障转移和后续选举的容错处理。从 MongoDB 3.6 开始，MongoDB 驱动程序可以检测到主节点的失联，并可以自动重试一次某些写入操作。

从 MongoDB4.4 开始，MongoDB 提供镜像读取：将可选举的从节点的最近访问的数据，预热为缓存。预热从节点的缓存可以帮助在选举后更快地恢复。

# 读操作

# 读优先

默认情况下，客户端从主节点读取数据；但是，客户端可以指定读取首选项，以将读取操作发送到从节点。

img

异步复制到从节点意味着向从节点读取数据可能会返回与主节点不一致的数据。

包含读取操作的多文档事务必须使用读取主节点优先。给定事务中的所有操作必须路由到同一成员。

# 数据可见性

根据读取的关注点，客户端可以在持久化写入前查看写入结果：

对于多文档事务中的操作，当事务提交时，在事务中进行的所有数据更改都将保存，并在事务外部可见。也就是说，事务在回滚其他事务时将不会提交其某些更改。在提交事务前，事务外部看不到在事务中进行的数据更改。

但是，当事务写入多个分片时，并非所有外部读操作都需要等待已提交事务的结果在所有分片上可见。例如，如果提交了一个事务，并且在分片 A 上可以看到写 1，但是在分片 B 上还看不到写 2，则在 "local" (opens new window) 读配置级别，外部读取可以读取写 1 的结果而看不到写 2。

# 镜像读取

从 MongoDB 4.4 开始，MongoDB 提供镜像读取以预热可选从节点（即优先级大于 0 的成员）的缓存。使用镜像读取（默认情况下已启用），主节点可以镜像它接收到的一部分操作，并将其发送给可选择的从节点的子集。子集的大小是可配置的。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#文档数据库#MongoDB#复制
上次更新: 2023/06/29, 22:27:04
MongoDB 索引
MongoDB 分片

+ ← + MongoDB 分片→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/52609d/index.html b/pages/52609d/index.html new file mode 100644 index 00000000..42bd84f0 --- /dev/null +++ b/pages/52609d/index.html @@ -0,0 +1,111 @@ + + + + + + PostgreSQL 应用指南 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2019-08-22
目录

PostgreSQL 应用指南

# PostgreSQL 应用指南

PostgreSQL (opens new window) 是一个关系型数据库（RDBM）。

关键词：Database, RDBM, psql

img

# 安装

本文仅以运行在 Centos 环境下举例。

进入官方下载页面 (opens new window)，根据操作系统选择合适版本。

官方下载页面要求用户选择相应版本，然后动态的给出安装提示，如下图所示：

img

前 3 步要求用户选择，后 4 步是根据选择动态提示的安装步骤

（1）选择 PostgreSQL 版本

（2）选择平台

（3）选择架构

（4）安装 PostgreSQL 的 rpm 仓库（为了识别下载源）

yum install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm
+

（5）安装客户端

yum install postgresql10
+

（6）安装服务端（可选的）

yum install postgresql10-server
+

（7）设置开机启动（可选的）

/usr/pgsql-10/bin/postgresql-10-setup initdb
+systemctl enable postgresql-10
+systemctl start postgresql-10
+

# 添加新用户和新数据库

初次安装后，默认生成一个名为 postgres 的数据库和一个名为 postgres 的数据库用户。这里需要注意的是，同时还生成了一个名为 postgres 的 Linux 系统用户。

首先，新建一个 Linux 新用户，可以取你想要的名字，这里为 dbuser。

sudo adduser dbuser
+

使用 psql 命令登录 PostgreSQL 控制台：

sudo -u postgres psql
+

这时相当于系统用户 postgres 以同名数据库用户的身份，登录数据库，这是不用输入密码的。如果一切正常，系统提示符会变为"postgres=#"，表示这时已经进入了数据库控制台。以下的命令都在控制台内完成。

（1）使用 \password 命令，为 postgres 用户设置一个密码。

postgres=# \password postgres
+

（2）创建数据库用户 dbuser（刚才创建的是 Linux 系统用户），并设置密码。

CREATE USER dbuser WITH PASSWORD 'password';
+

（3）创建用户数据库，这里为 exampledb，并指定所有者为 dbuser。

CREATE DATABASE exampledb OWNER dbuser;
+

（4）将 exampledb 数据库的所有权限都赋予 dbuser，否则 dbuser 只能登录控制台，没有任何数据库操作权限。

GRANT ALL PRIVILEGES ON DATABASE exampledb to dbuser;
+

（5）使用\q 命令退出控制台（也可以直接按 ctrl+D）。

# 登录数据库

添加新用户和新数据库以后，就要以新用户的名义登录数据库，这时使用的是 psql 命令。

psql -U dbuser -d exampledb -h 127.0.0.1 -p 5432
+

上面命令的参数含义如下：-U 指定用户，-d 指定数据库，-h 指定服务器，-p 指定端口。

输入上面命令以后，系统会提示输入 dbuser 用户的密码。输入正确，就可以登录控制台了。

psql 命令存在简写形式。如果当前 Linux 系统用户，同时也是 PostgreSQL 用户，则可以省略用户名（-U 参数的部分）。举例来说，我的 Linux 系统用户名为 ruanyf，且 PostgreSQL 数据库存在同名用户，则我以 ruanyf 身份登录 Linux 系统后，可以直接使用下面的命令登录数据库，且不需要密码。

psql exampledb
+

此时，如果 PostgreSQL 内部还存在与当前系统用户同名的数据库，则连数据库名都可以省略。比如，假定存在一个叫做 ruanyf 的数据库，则直接键入 psql 就可以登录该数据库。

psql

另外，如果要恢复外部数据，可以使用下面的命令。

psql exampledb < exampledb.sql
+

# 控制台命令

除了前面已经用到的 \password 命令（设置密码）和 \q 命令（退出）以外，控制台还提供一系列其他命令。

\password           设置密码
+\q                  退出
+\h                  查看SQL命令的解释，比如\h select
+\?                  查看psql命令列表
+\l                  列出所有数据库
+\c [database_name]  连接其他数据库
+\d                  列出当前数据库的所有表格
+\d [table_name]     列出某一张表格的结构
+\x                  对数据做展开操作
+\du                 列出所有用户
+

# 数据库操作

基本的数据库操作，就是使用一般的 SQL 语言。

# 创建新表
+CREATE TABLE user_tbl(name VARCHAR(20), signup_date DATE);
+# 插入数据
+INSERT INTO user_tbl(name, signup_date) VALUES('张三', '2013-12-22');
+# 选择记录
+SELECT * FROM user_tbl;
+# 更新数据
+UPDATE user_tbl set name = '李四' WHERE name = '张三';
+# 删除记录
+DELETE FROM user_tbl WHERE name = '李四' ;
+# 添加栏位
+ALTER TABLE user_tbl ADD email VARCHAR(40);
+# 更新结构
+ALTER TABLE user_tbl ALTER COLUMN signup_date SET NOT NULL;
+# 更名栏位
+ALTER TABLE user_tbl RENAME COLUMN signup_date TO signup;
+# 删除栏位
+ALTER TABLE user_tbl DROP COLUMN email;
+# 表格更名
+ALTER TABLE user_tbl RENAME TO backup_tbl;
+# 删除表格
+DROP TABLE IF EXISTS backup_tbl;
+

# 备份和恢复

pg_dump --format=t -d db_name -U user_name -h 127.0.0.1 -O -W  > dump.sql
+psql -h 127.0.0.1 -U user_name db_name < dump.sql
+

# 参考资料

  • https://www.postgresql.org/download/
  • http://www.ruanyifeng.com/blog/2013/12/getting_started_with_postgresql.html

# 🚪 传送门

| 钝悟的博客 (opens new window) | db-tutorial 首页 (opens new window) |

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#PostgreSQL
上次更新: 2023/06/29, 22:27:04
Mysql 常见问题
H2 应用指南

+ ← + H2 应用指南→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/537098/index.html b/pages/537098/index.html new file mode 100644 index 00000000..25f95688 --- /dev/null +++ b/pages/537098/index.html @@ -0,0 +1,267 @@ + + + + + + Redis 运维 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-24
目录

Redis 运维

# Redis 运维

Redis 是一个高性能的 key-value 数据库。

SET 操作每秒钟 110000 次；GET 操作每秒钟 81000 次。

# 一、Redis 安装

# Window 下安装

下载地址：https://github.com/MSOpenTech/redis/releases (opens new window)。

Redis 支持 32 位和 64 位。这个需要根据你系统平台的实际情况选择，这里我们下载 Redis-x64-xxx.zip压缩包到 C 盘，解压后，将文件夹重新命名为 redis。

打开一个 cmd 窗口 使用 cd 命令切换目录到 C:\redis 运行 redis-server.exe redis.windows.conf 。

如果想方便的话，可以把 redis 的路径加到系统的环境变量里，这样就省得再输路径了，后面的那个 redis.windows.conf 可以省略，如果省略，会启用默认的。

这时候另启一个 cmd 窗口，原来的不要关闭，不然就无法访问服务端了。

切换到 redis 目录下运行 redis-cli.exe -h 127.0.0.1 -p 6379 。

# Linux 下安装

下载地址： http://redis.io/download，下载最新文档版本。

下载、解压、编译 Redis

wget http://download.redis.io/releases/redis-5.0.4.tar.gz
+tar xzf redis-5.0.4.tar.gz
+cd redis-5.0.4
+make
+

为了编译 Redis 源码，你需要 gcc-c++和 tcl。如果你的系统是 CentOS，可以直接执行命令：yum install -y gcc-c++ tcl 来安装。

进入到解压后的 src 目录，通过如下命令启动 Redis:

src/redis-server
+

您可以使用内置的客户端与 Redis 进行交互:

$ src/redis-cli
+redis> set foo bar
+OK
+redis> get foo
+"bar"
+

# Ubuntu 下安装

在 Ubuntu 系统安装 Redis 可以使用以下命令:

sudo apt-get update
+sudo apt-get install redis-server
+

# 开机启动

  • 开机启动配置：echo "/usr/local/bin/redis-server /etc/redis.conf" >> /etc/rc.local

# 开放防火墙端口

  • 添加规则：iptables -I INPUT -p tcp -m tcp --dport 6379 -j ACCEPT
  • 保存规则：service iptables save
  • 重启 iptables：service iptables restart

# Redis 安装脚本

CentOS7 环境安装脚本：软件运维配置脚本集合 (opens new window)

安装说明

  • 采用编译方式安装 Redis, 并将其注册为 systemd 服务
  • 安装路径为：/usr/local/redis
  • 默认下载安装 5.0.4 版本，端口号为：6379，密码为空

使用方法

  • 默认安装 - 执行以下任意命令即可：
curl -o- https://gitee.com/turnon/linux-tutorial/raw/master/codes/linux/soft/redis-install.sh | bash
+wget -qO- https://gitee.com/turnon/linux-tutorial/raw/master/codes/linux/soft/redis-install.sh | bash
+
  • 自定义安装 - 下载脚本到本地，并按照以下格式执行：
sh redis-install.sh [version] [port] [password]
+

参数说明：

  • version - redis 版本号
  • port - redis 服务端口号
  • password - 访问密码

# 二、Redis 单机使用和配置

# 启动 Redis

启动 redis 服务

cd /usr/local/redis/src
+./redis-server
+

启动 redis 客户端

cd /usr/local/redis/src
+./redis-cli
+

查看 redis 是否启动

redis-cli
+

以上命令将打开以下终端：

redis 127.0.0.1:6379>
+

127.0.0.1 是本机 IP ，6379 是 redis 服务端口。现在我们输入 PING 命令。

redis 127.0.0.1:6379> ping
+PONG
+

以上说明我们已经成功启动了 redis。

# Redis 常见配置

Redis 默认的配置文件是根目录下的 redis.conf 文件。

如果需要指定特定文件作为配置文件，需要使用命令： ./redis-server -c xxx.conf

每次修改配置后，需要重启才能生效。

Redis 官方默认配置：

自 Redis2.6 起就可以直接通过命令行传递 Redis 配置参数。这种方法可以用于测试。自 Redis2.6 起就可以直接通过命令行传递 Redis 配置参数。这种方法可以用于测试。

# 设为守护进程

Redis 默认以非守护进程方式启动，而通常我们会将 Redis 设为守护进程启动方式，配置：daemonize yes

# 远程访问

Redis 默认绑定 127.0.0.1，这样就只能本机才能访问，若要 Redis 允许远程访问，需要配置：bind 0.0.0.0

# 设置密码

Redis 默认访问不需要密码，如果需要设置密码，需要如下配置：

  • protected-mode yes
  • requirepass <密码>

# 配置参数表

配置项 说明
daemonize no Redis 默认不是以守护进程的方式运行，可以通过该配置项修改，使用 yes 启用守护进程（Windows 不支持守护线程的配置为 no ）
pidfile /var/run/redis.pid 当 Redis 以守护进程方式运行时，Redis 默认会把 pid 写入 /var/run/redis.pid 文件，可以通过 pidfile 指定
port 6379 指定 Redis 监听端口，默认端口为 6379，作者在自己的一篇博文中解释了为什么选用 6379 作为默认端口，因为 6379 在手机按键上 MERZ 对应的号码，而 MERZ 取自意大利歌女 Alessia Merz 的名字
bind 127.0.0.1 绑定的主机地址
timeout 300 当客户端闲置多长时间后关闭连接，如果指定为 0，表示关闭该功能
loglevel notice 指定日志记录级别，Redis 总共支持四个级别：debug、verbose、notice、warning，默认为 notice
logfile stdout 日志记录方式，默认为标准输出，如果配置 Redis 为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给 /dev/null
databases 16 设置数据库的数量，默认数据库为 0，可以使用 SELECT 命令在连接上指定数据库 id
save <seconds> <changes> Redis 默认配置文件中提供了三个条件：save 900 1、save 300 10、save 60 10000 分别表示 900 秒（15 分钟）内有 1 个更改，300 秒（5 分钟）内有 10 个更改以及 60 秒内有 10000 个更改。 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
rdbcompression yes 指定存储至本地数据库时是否压缩数据，默认为 yes，Redis 采用 LZF 压缩，如果为了节省 CPU 时间，可以关闭该选项，但会导致数据库文件变的巨大
dbfilename dump.rdb 指定本地数据库文件名，默认值为 dump.rdb
dir ./ 指定本地数据库存放目录
slaveof <masterip> <masterport> 设置当本机为 slav 服务时，设置 master 服务的 IP 地址及端口，在 Redis 启动时，它会自动从 master 进行数据同步
masterauth <master-password> 当 master 服务设置了密码保护时，slav 服务连接 master 的密码
requirepass foobared 设置 Redis 连接密码，如果配置了连接密码，客户端在连接 Redis 时需要通过 AUTH <password> 命令提供密码，默认关闭
maxclients 128 设置同一时间最大客户端连接数，默认无限制，Redis 可以同时打开的客户端连接数为 Redis 进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis 会关闭新的连接并向客户端返回 max number of clients reached 错误信息
maxmemory <bytes> 指定 Redis 最大内存限制，Redis 在启动时会把数据加载到内存中，达到最大内存后，Redis 会先尝试清除已到期或即将到期的 Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis 新的 vm 机制，会把 Key 存放内存，Value 会存放在 swap 区
appendonly no 指定是否在每次更新操作后进行日志记录，Redis 在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis 本身同步数据文件是按上面 save 条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为 no
appendfilename appendonly.aof 指定更新日志文件名，默认为 appendonly.aof
appendfsync everysec 指定更新日志条件，共有 3 个可选值：no：表示等操作系统进行数据缓存同步到磁盘（快）always：表示每次更新操作后手动调用 fsync() 将数据写到磁盘（慢，安全）everysec：表示每秒同步一次（折中，默认值）
vm-enabled no 指定是否启用虚拟内存机制，默认值为 no，简单的介绍一下，VM 机制将数据分页存放，由 Redis 将访问量较少的页即冷数据 swap 到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析 Redis 的 VM 机制）
vm-swap-file /tmp/redis.swap 虚拟内存文件路径，默认值为 /tmp/redis.swap，不可多个 Redis 实例共享
vm-max-memory 0 将所有大于 vm-max-memory 的数据存入虚拟内存，无论 vm-max-memory 设置多小，所有索引数据都是内存存储的(Redis 的索引数据 就是 keys)，也就是说，当 vm-max-memory 设置为 0 的时候，其实是所有 value 都存在于磁盘。默认值为 0
vm-page-size 32 Redis swap 文件分成了很多的 page，一个对象可以保存在多个 page 上面，但一个 page 上不能被多个对象共享，vm-page-size 是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page 大小最好设置为 32 或者 64bytes；如果存储很大大对象，则可以使用更大的 page，如果不确定，就使用默认值
vm-pages 134217728 设置 swap 文件中的 page 数量，由于页表（一种表示页面空闲或使用的 bitmap）是在放在内存中的，，在磁盘上每 8 个 pages 将消耗 1byte 的内存。
vm-max-threads 4 设置访问 swap 文件的线程数,最好不要超过机器的核数,如果设置为 0,那么所有对 swap 文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为 4
glueoutputbuf yes 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
hash-max-zipmap-entries 64 hash-max-zipmap-value 512 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
activerehashing yes 指定是否激活重置哈希，默认为开启（后面在介绍 Redis 的哈希算法时具体介绍）
include /path/to/local.conf 指定包含其它的配置文件，可以在同一主机上多个 Redis 实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件

# 压力测试

参考官方文档：How fast is Redis? (opens new window)

Redis 自带了一个性能测试工具：redis-benchmark

（1）基本测试

redis-benchmark -q -n 100000
+
  • -q 表示静默（quiet）执行
  • -n 100000 请求 10 万次

（2）测试指定读写指令

$ redis-benchmark -t set,lpush -n 100000 -q
+SET: 74239.05 requests per second
+LPUSH: 79239.30 requests per second
+

（3）测试 pipeline 模式下指定读写指令

redis-benchmark -n 1000000 -t set,get -P 16 -q
+SET: 403063.28 requests per second
+GET: 508388.41 requests per second
+

# 三、Redis 集群使用和配置

Redis 3.0 后支持集群模式。

# 集群规划

Redis 集群一般由 多个节点 组成，节点数量至少为 6 个，才能保证组成 完整高可用 的集群。

img

理想情况当然是所有节点各自在不同的机器上，首先于资源，本人在部署 Redis 集群时，只得到 3 台服务器。所以，我计划每台服务器部署 2 个 Redis 节点。

【示例】最简高可用 Redis 集群规划

机器配置：16G 内存 + 8 核 CPU + 1T 磁盘

Redis 进程分配 10 G 内存。一般线上生产环境，Redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。

集群拓扑：三主三从；三哨兵，每个哨兵监听所有主节点。

估算性能：

  • 容量：三主，占用 30 G 内存，所以最大存储容量为 30 G。假设每条数据记录平均 大小为 10 K，则最大能存储 300 万条数据。
  • 吞吐量：单机一般 TPS/QPS 为 五万到八万左右。假设为五万，那么三主三从架构理论上能达到 TPS 15 万，QPS 30 万。

# 部署集群

Redis 集群节点的安装与单节点服务相同，差异仅在于部署方式。

注意：为了演示方便，本示例将所有 Redis 集群节点都部署在一台机器上，实际生产环境中，基本都会将节点部署在不同机器上。要求更高的，可能还要考虑多机房部署。

（1）创建节点目录

我个人偏好将软件放在 /opt 目录下，在我的机器中，Redis 都安装在 /usr/local/redis 目录下。所以，下面的命令和配置都假设 Redis 安装目录为 /usr/local/redis 。

确保机器上已经安装了 Redis 后，执行以下命令，创建 Redis 集群节点实例目录：

sudo mkdir -p /usr/local/redis/conf/7001
+sudo mkdir -p /usr/local/redis/conf/7002
+sudo mkdir -p /usr/local/redis/conf/7003
+sudo mkdir -p /usr/local/redis/conf/7004
+sudo mkdir -p /usr/local/redis/conf/7005
+sudo mkdir -p /usr/local/redis/conf/7006
+

（2）配置集群节点

每个实例目录下，新建 redis.conf 配置文件。

实例配置模板以 7001 节点为例（其他节点，完全替换配置中的端口号 7001 即可），如下：

# 端口号
+port 7001
+# 绑定的主机端口（0.0.0.0 表示允许远程访问）
+bind 0.0.0.0
+# 以守护进程方式启动
+daemonize yes
+
+# 开启集群模式
+cluster-enabled yes
+# 集群的配置，配置文件首次启动自动生成
+cluster-config-file /usr/local/redis/conf/7001/7001.conf
+# 请求超时时间，设置 10 秒
+cluster-node-timeout 10000
+
+# 开启 AOF 持久化
+appendonly yes
+# 数据存放目录
+dir /usr/local/redis/conf/7001
+# 进程文件
+pidfile /usr/local/redis/conf/7001/7001.pid
+# 日志文件
+logfile /usr/local/redis/conf/7001/7001.log
+

（3）批量启动 Redis 节点

Redis 的 utils/create-cluster 目录下自带了一个名为 create-cluster 的脚本工具，可以利用它来新建、启动、停止、重启 Redis 节点。

脚本中有几个关键参数：

  • PORT=30000 - 初始端口号
  • TIMEOUT=2000 - 超时时间
  • NODES=6 - 节点数
  • REPLICAS=1 - 备份数

脚本中的每个命令项会根据初始端口号，以及设置的节点数，遍历的去执行操作。

由于前面的规划中，节点端口是从 7001 ~ 7006，所以需要将 PORT 变量设为 7000。

脚本中启动每个 Redis 节点是通过指定命令行参数来配置属性。所以，我们需要改一下：

PORT=7000
+TIMEOUT=2000
+NODES=6
+ENDPORT=$((PORT+NODES))
+
+# ...
+
+if [ "$1" == "start" ]
+then
+    while [ $((PORT < ENDPORT)) != "0" ]; do
+        PORT=$((PORT+1))
+        echo "Starting $PORT"
+        /usr/local/redis/src/redis-server /usr/local/redis/conf/${PORT}/redis.conf
+    done
+    exit 0
+fi
+

好了，在每台服务器上，都执行 ./create-cluster start 来启动节点。

然后，通过 ps 命令来确认 Redis 进程是否已经工作：

# root @ dbClusterDev01 in /usr/local/redis/conf [11:07:55]
+$ ps -ef | grep redis
+root      4604     1  0 11:07 ?        00:00:00 /opt/redis/src/redis-server 0.0.0.0:7001 [cluster]
+root      4609     1  0 11:07 ?        00:00:00 /opt/redis/src/redis-server 0.0.0.0:7002 [cluster]
+root      4614     1  0 11:07 ?        00:00:00 /opt/redis/src/redis-server 0.0.0.0:7003 [cluster]
+root      4619     1  0 11:07 ?        00:00:00 /opt/redis/src/redis-server 0.0.0.0:7004 [cluster]
+root      4624     1  0 11:07 ?        00:00:00 /opt/redis/src/redis-server 0.0.0.0:7005 [cluster]
+root      4629     1  0 11:07 ?        00:00:00 /opt/redis/src/redis-server 0.0.0.0:7006 [cluster]
+

（4）启动集群

通过 redis-cli --cluster create 命令可以自动配置集群，如下：

./redis-cli --cluster create 127.0.0.1:7001 127.0.0.1:7002 127.0.0.2:7003 127.0.0.2:7004 127.0.0.3:7005 127.0.0.3:7006 --cluster-replicas 1
+

redis-cluster 会根据设置的节点数和副本数自动分片（分配 Hash 虚拟槽 slot），如果满意，输入 yes ，直接开始分片。

>>> Performing hash slots allocation on 6 nodes...
+Master[0] -> Slots 0 - 5460
+Master[1] -> Slots 5461 - 10922
+Master[2] -> Slots 10923 - 16383
+Adding replica 127.0.0.2:7004 to 127.0.0.1:7001
+Adding replica 127.0.0.3:7006 to 127.0.0.2:7003
+Adding replica 127.0.0.1:7002 to 127.0.0.3:7005
+M: b721235997deb6b9a7a2be690b5b9663db8057c6 127.0.0.1:7001
+   slots:[0-5460] (5461 slots) master
+S: bda9b7036df0bbefe601bda4ce45d3787a2e9bd9 127.0.0.1:7002
+   replicates 3623fff69b5243ed18c02a2fbb6f53069b0f1505
+M: 91523c0391a044da6cc9f53bb965aabe89502187 127.0.0.2:7003
+   slots:[5461-10922] (5462 slots) master
+S: 9d899cbe49dead7b8c4f769920cdb75714a441ae 127.0.0.2:7004
+   replicates b721235997deb6b9a7a2be690b5b9663db8057c6
+M: 3623fff69b5243ed18c02a2fbb6f53069b0f1505 127.0.0.3:7005
+   slots:[10923-16383] (5461 slots) master
+S: a2869dc153ea4977ca790b76483574a5d56cb40e 127.0.0.3:7006
+   replicates 91523c0391a044da6cc9f53bb965aabe89502187
+Can I set the above configuration? (type 'yes' to accept): yes
+>>> Nodes configuration updated
+>>> Assign a different config epoch to each node
+>>> Sending CLUSTER MEET messages to join the cluster
+Waiting for the cluster to join
+....
+>>> Performing Cluster Check (using node 127.0.0.1:7001)
+M: b721235997deb6b9a7a2be690b5b9663db8057c6 127.0.0.1:7001
+   slots:[0-5460] (5461 slots) master
+   1 additional replica(s)
+S: a2869dc153ea4977ca790b76483574a5d56cb40e 127.0.0.1:7006
+   slots: (0 slots) slave
+   replicates 91523c0391a044da6cc9f53bb965aabe89502187
+M: 91523c0391a044da6cc9f53bb965aabe89502187 127.0.0.1:7003
+   slots:[5461-10922] (5462 slots) master
+   1 additional replica(s)
+M: 3623fff69b5243ed18c02a2fbb6f53069b0f1505 127.0.0.1:7005
+   slots:[10923-16383] (5461 slots) master
+   1 additional replica(s)
+S: 9d899cbe49dead7b8c4f769920cdb75714a441ae 127.0.0.1:7004
+   slots: (0 slots) slave
+   replicates b721235997deb6b9a7a2be690b5b9663db8057c6
+S: bda9b7036df0bbefe601bda4ce45d3787a2e9bd9 127.0.0.1:7002
+   slots: (0 slots) slave
+   replicates 3623fff69b5243ed18c02a2fbb6f53069b0f1505
+[OK] All nodes agree about slots configuration.
+>>> Check for open slots...
+>>> Check slots coverage...
+[OK] All 16384 slots covered.
+

（5）日常维护操作

  • 关闭集群 - ./create-cluster stop
  • 检查集群是否健康（指定任意节点即可）：./redis-cli --cluster check <ip:port>
  • 尝试修复集群节点：./redis-cli --cluster fix <ip:port>

# 部署哨兵

redis-cluster 实现了 Redis 的分片、复制。

但 redis-cluster 没有解决故障转移问题，一旦任意分片的 Master 节点宕机、网络不通，就会导致 redis-cluster 的集群不能工作。为了解决高可用的问题，Redis 提供了 Redis 哨兵来监控 Redis 节点状态，并且会在 Master 宕机时，发起选举，将这个 Master 的一个 Slave 节点选举为 Master。

（1）创建节点目录

我个人偏好将软件放在 /opt 目录下，在我的机器中，Redis 都安装在 /usr/local/redis 目录下。所以，下面的命令和配置都假设 Redis 安装目录为 /usr/local/redis 。

确保机器上已经安装了 Redis 后，执行以下命令，创建 Redis 集群节点实例目录：

sudo mkdir -p /usr/local/redis/conf/27001
+sudo mkdir -p /usr/local/redis/conf/27002
+sudo mkdir -p /usr/local/redis/conf/27003
+

（2）配置集群节点

每个实例目录下，新建 redis.conf 配置文件。

实例配置模板以 7001 节点为例（其他节点，完全替换配置中的端口号 7001 即可），如下：

port 27001
+daemonize yes
+sentinel monitor redis-master 172.22.6.3 7001 2
+sentinel down-after-milliseconds redis-master 5000
+sentinel failover-timeout redis-master 900000
+sentinel parallel-syncs redis-master 1
+#sentinel auth-pass redis-master 123456
+logfile /usr/local/redis/conf/27001/27001.log
+

（3）批量启动哨兵节点

/opt/redis/src/redis-sentinel /usr/local/redis/conf/27001/sentinel.conf
+/opt/redis/src/redis-sentinel /usr/local/redis/conf/27002/sentinel.conf
+/opt/redis/src/redis-sentinel /usr/local/redis/conf/27003/sentinel.conf
+

# 扩容

（1）查看信息

进入任意节点

./redis-cli -h 172.22.6.3 -p 7001
+

cluster info 查看集群节点状态

172.22.6.3:7001> cluster nodes
+f158bf70bb2767cac271ce4efcfc14ba0b7ca98b 172.22.6.3:7006@17006 slave e7aa182e756b76ec85b471797db9b66e4b2da725 0 1594528179000 6 connected
+f348e67648460c7a800120d69b4977bf2e4524cb 172.22.6.3:7001@17001 myself,master - 0 1594528179000 1 connected 0-5460
+52601e2d4af0e64b83f4cc6d20e8316d0ac38b99 172.22.6.3:7004@17004 slave 4802fafe897160c46392c6e569d6f5e466cca696 0 1594528178000 4 connected
+c6c6a68674ae8aac3c6ec792c8af4dc1228c6c31 172.22.6.3:7005@17005 slave f348e67648460c7a800120d69b4977bf2e4524cb 0 1594528179852 5 connected
+e7aa182e756b76ec85b471797db9b66e4b2da725 172.22.6.3:7002@17002 master - 0 1594528178000 2 connected 5461-10922
+4802fafe897160c46392c6e569d6f5e466cca696 172.22.6.3:7003@17003 master - 0 1594528178000 3 connected 10923-16383
+

cluster info 查看集群信息

172.22.6.3:7001> cluster info
+cluster_state:ok
+cluster_slots_assigned:16384
+cluster_slots_ok:16384
+cluster_slots_pfail:0
+cluster_slots_fail:0
+cluster_known_nodes:6
+cluster_size:3
+cluster_current_epoch:6
+cluster_my_epoch:1
+cluster_stats_messages_ping_sent:3406
+cluster_stats_messages_pong_sent:3569
+cluster_stats_messages_publish_sent:5035
+cluster_stats_messages_sent:12010
+cluster_stats_messages_ping_received:3564
+cluster_stats_messages_pong_received:3406
+cluster_stats_messages_meet_received:5
+cluster_stats_messages_publish_received:5033
+cluster_stats_messages_received:12008
+

（2）添加节点到集群

将已启动的节点实例添加到集群中

redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7008
+

添加主节点

添加一组主节点

./redis-cli --cluster add-node 172.22.6.3:7007 172.22.6.3:7001
+./redis-cli --cluster add-node 172.22.6.3:7008 172.22.6.3:7001
+./redis-cli --cluster add-node 172.22.6.3:7009 172.22.6.3:7001
+

查看节点状态

172.22.6.3:7001> cluster nodes
+f158bf70bb2767cac271ce4efcfc14ba0b7ca98b 172.22.6.3:7006@17006 slave e7aa182e756b76ec85b471797db9b66e4b2da725 0 1594529342575 6 connected
+f348e67648460c7a800120d69b4977bf2e4524cb 172.22.6.3:7001@17001 myself,master - 0 1594529340000 1 connected 0-5460
+55cacf121662833a4a19dbeb4a5df712cfedf77f 172.22.6.3:7009@17009 master - 0 1594529342000 0 connected
+c6c6a68674ae8aac3c6ec792c8af4dc1228c6c31 172.22.6.3:7005@17005 slave f348e67648460c7a800120d69b4977bf2e4524cb 0 1594529341573 5 connected
+4802fafe897160c46392c6e569d6f5e466cca696 172.22.6.3:7003@17003 master - 0 1594529343577 3 connected 10923-16383
+e7aa182e756b76ec85b471797db9b66e4b2da725 172.22.6.3:7002@17002 master - 0 1594529342000 2 connected 5461-10922
+e5ba78fe629115977a74fbbe1478caf8868d6d55 172.22.6.3:7007@17007 master - 0 1594529341000 0 connected
+52601e2d4af0e64b83f4cc6d20e8316d0ac38b99 172.22.6.3:7004@17004 slave 4802fafe897160c46392c6e569d6f5e466cca696 0 1594529340000 4 connected
+79d4fffc2cec210556c3b4c44e63ab506e87eda3 172.22.6.3:7008@17008 master - 0 1594529340000 7 connected
+

可以发现，新加入的三个主节点，还没有分配哈希槽，所以，暂时还无法访问。

添加从节点

--slave：设置该参数，则新节点以 slave 的角色加入集群
+--master-id：这个参数需要设置了--slave 才能生效，--master-id 用来指定新节点的 master 节点。如果不设置该参数，则会随机为节点选择 master 节点。

语法

redis-cli --cluster add-node  新节点IP地址：端口    存在节点IP：端口 --cluster-slave （从节点） --cluster-master-id （master节点的ID）
+redis-cli --cluster add-node   10.42.141.119:6379  10.42.166.105:6379  --cluster-slave   --cluster-master-id  dfa238fff8a7a49230cff7eb74f573f5645c8ec5
+

示例

./redis-cli --cluster add-node 172.22.6.3:7010 172.22.6.3:7007 --cluster-slave
+./redis-cli --cluster add-node 172.22.6.3:7011 172.22.6.3:7008 --cluster-slave
+./redis-cli --cluster add-node 172.22.6.3:7012 172.22.6.3:7009 --cluster-slave
+

查看状态

172.22.6.3:7001> cluster nodes
+ef5c1b9ce4cc795dc12b2c1e8736a572647b4c3e 172.22.6.3:7011@17011 slave 79d4fffc2cec210556c3b4c44e63ab506e87eda3 0 1594529492043 7 connected
+f158bf70bb2767cac271ce4efcfc14ba0b7ca98b 172.22.6.3:7006@17006 slave e7aa182e756b76ec85b471797db9b66e4b2da725 0 1594529491943 6 connected
+f348e67648460c7a800120d69b4977bf2e4524cb 172.22.6.3:7001@17001 myself,master - 0 1594529488000 1 connected 0-5460
+5140d1129ed850df59c51cf818c4eb74545d9959 172.22.6.3:7010@17010 slave e5ba78fe629115977a74fbbe1478caf8868d6d55 0 1594529488000 0 connected
+55cacf121662833a4a19dbeb4a5df712cfedf77f 172.22.6.3:7009@17009 master - 0 1594529488000 8 connected
+c6c6a68674ae8aac3c6ec792c8af4dc1228c6c31 172.22.6.3:7005@17005 slave f348e67648460c7a800120d69b4977bf2e4524cb 0 1594529490000 5 connected
+4802fafe897160c46392c6e569d6f5e466cca696 172.22.6.3:7003@17003 master - 0 1594529489939 3 connected 10923-16383
+e7aa182e756b76ec85b471797db9b66e4b2da725 172.22.6.3:7002@17002 master - 0 1594529491000 2 connected 5461-10922
+e5ba78fe629115977a74fbbe1478caf8868d6d55 172.22.6.3:7007@17007 master - 0 1594529490942 0 connected
+52601e2d4af0e64b83f4cc6d20e8316d0ac38b99 172.22.6.3:7004@17004 slave 4802fafe897160c46392c6e569d6f5e466cca696 0 1594529491000 4 connected
+02e9f57b5b45c350dc57acf1c8efa8db136db7b7 172.22.6.3:7012@17012 master - 0 1594529489000 0 connected
+79d4fffc2cec210556c3b4c44e63ab506e87eda3 172.22.6.3:7008@17008 master - 0 1594529489000 7 connected
+

分配哈希槽

执行 ./redis-cli --cluster rebalance 172.22.6.3:7001 --cluster-threshold 1 --cluster-use-empty-masters

参数说明：

rebalance：表明让 Redis 自动根据节点数进行均衡哈希槽分配。

--cluster-use-empty-masters：表明

img

执行结束后，查看状态：

img

# 四、Redis 命令

# 通用命令

命令详细用法，请参考 Redis 命令官方文档 (opens new window)

搬迁两张 cheat sheet 图，原址：https://www.cheatography.com/tasjaevan/cheat-sheets/redis/

img

img

# 集群命令

  • 集群
    • cluster info - 打印集群的信息
    • cluster nodes - 列出集群当前已知的所有节点（ node），以及这些节点的相关信息。
  • 节点
    • cluster meet <ip> <port> - 将 ip 和 port 所指定的节点添加到集群当中，让它成为集群的一份子。
    • cluster forget <node_id> - 从集群中移除 node_id 指定的节点。
    • cluster replicate <node_id> - 将当前节点设置为 node_id 指定的节点的从节点。
    • cluster saveconfig - 将节点的配置文件保存到硬盘里面。
  • 槽(slot)
    • cluster addslots <slot> [slot ...] - 将一个或多个槽（ slot）指派（ assign）给当前节点。
    • cluster delslots <slot> [slot ...] - 移除一个或多个槽对当前节点的指派。
    • cluster flushslots - 移除指派给当前节点的所有槽，让当前节点变成一个没有指派任何槽的节点。
    • cluster setslot <slot> node <node_id> - 将槽 slot 指派给 node_id 指定的节点，如果槽已经指派给另一个节点，那么先让另一个节点删除该槽>，然后再进行指派。
    • cluster setslot <slot> migrating <node_id> - 将本节点的槽 slot 迁移到 node_id 指定的节点中。
    • cluster setslot <slot> importing <node_id> - 从 node_id 指定的节点中导入槽 slot 到本节点。
    • cluster setslot <slot> stable - 取消对槽 slot 的导入（ import）或者迁移（ migrate）。
  • 键
    • cluster keyslot <key> - 计算键 key 应该被放置在哪个槽上。
    • cluster countkeysinslot <slot> - 返回槽 slot 目前包含的键值对数量。
    • cluster getkeysinslot <slot> <count> - 返回 count 个 slot 槽中的键。

# 重新分片

添加节点：./redis-cli --cluster add-node 192.168.1.136:7007 192.168.1.136:7001 --cluster-slave

redis-cli --cluster reshard 172.22.6.3 7001

# 五、客户端

推荐使用 RedisDesktopManager (opens new window)

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#KV数据库#Redis#运维
上次更新: 2023/06/29, 22:27:04
Redis 实战
HBase 快速入门

+ ← + HBase 快速入门→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/553160/index.html b/pages/553160/index.html new file mode 100644 index 00000000..17a8a5d1 --- /dev/null +++ b/pages/553160/index.html @@ -0,0 +1,67 @@ + + + + + + Elastic 快速入门 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-16
目录

Elastic 快速入门

# Elastic 快速入门

开源协议：Apache 2.0 (opens new window)

# 1. 简介

# 1.1. Elastic Stack 是什么

Elastic Stack 即 ELK Stack。

ELK 是指 Elastic 公司旗下三款产品 ElasticSearch (opens new window) 、Logstash (opens new window) 、Kibana (opens new window) 的首字母组合。

  • Elasticsearch 是一个搜索和分析引擎。
  • Logstash 是服务器端数据处理管道，能够同时从多个来源采集数据，转换数据，然后将数据发送到诸如 Elasticsearch 等“存储库”中。
  • Kibana 则可以让用户在 Elasticsearch 中使用图形和图表对数据进行可视化。

而 Elastic Stack 是 ELK Stack 的更新换代产品，最新产品引入了轻量型的单一功能数据采集器，并把它们叫做 Beats (opens new window)。

# 1.2. 为什么使用 Elastic Stack

对于有一定规模的公司来说，通常会很多个应用，并部署在大量的服务器上。运维和开发人员常常需要通过查看日志来定位问题。如果应用是集群化部署，试想如果登录一台台服务器去查看日志，是多么费时费力。

而通过 ELK 这套解决方案，可以同时实现日志收集、日志搜索和日志分析的功能。

# 1.3. Elastic Stack 架构

img

说明

以上是 Elastic Stack 的一个架构图。从图中可以清楚的看到数据流向。

  • Beats (opens new window) 是单一用途的数据传输平台，它可以将多台机器的数据发送到 Logstash 或 ElasticSearch。但 Beats 并不是不可或缺的一环，所以本文中暂不介绍。

  • Logstash (opens new window) 是一个动态数据收集管道。支持以 TCP/UDP/HTTP 多种方式收集数据（也可以接受 Beats 传输来的数据），并对数据做进一步丰富或提取字段处理。

  • ElasticSearch (opens new window) 是一个基于 JSON 的分布式的搜索和分析引擎。作为 ELK 的核心，它集中存储数据。

  • Kibana (opens new window) 是 ELK 的用户界面。它将收集的数据进行可视化展示（各种报表、图形化数据），并提供配置、管理 ELK 的界面。

# 2. ElasticSearch

Elasticsearch (opens new window) 是一个分布式、RESTful 风格的搜索和数据分析引擎，能够解决不断涌现出的各种用例。 作为 Elastic Stack 的核心，它集中存储您的数据，帮助您发现意料之中以及意料之外的情况。

# 2.1. ElasticSearch 简介

Elasticsearch (opens new window) 基于搜索库 Lucene (opens new window) 开发。ElasticSearch 隐藏了 Lucene 的复杂性，提供了简单易用的 REST API / Java API 接口（另外还有其他语言的 API 接口）。

ElasticSearch 可以视为一个文档存储，它将复杂数据结构序列化为 JSON 存储。

ElasticSearch 是近乎于实时的全文搜素，这是指：

  • 从写入数据到数据可以被搜索，存在较小的延迟（大概是 1s）
  • 基于 ES 执行搜索和分析可以达到秒级

# 2.1.1. 核心概念

  • 索引（Index） 可以认为是文档（document）的优化集合。
  • 每个 文档（document） 都是字段（field）的集合。
  • 字段（field） 是包含数据的键值对。
  • 默认情况下，Elasticsearch 对每个字段中的所有数据建立索引，并且每个索引字段都具有专用的优化数据结构。
  • 每个索引里可以有一个或者多个类型（type）。类型（type） 是 index 的一个逻辑分类，
  • 当单台机器不足以存储大量数据时，Elasticsearch 可以将一个索引中的数据切分为多个 分片（shard） 。 分片（shard） 分布在多台服务器上存储。有了 shard 就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。每个 shard 都是一个 lucene index。
  • 任何一个服务器随时可能故障或宕机，此时 shard 可能就会丢失，因此可以为每个 shard 创建多个 副本（replica）。replica 可以在 shard 故障时提供备用服务，保证数据不丢失，多个 replica 还可以提升搜索操作的吞吐量和性能。primary shard（建立索引时一次设置，不能修改，默认 5 个），replica shard（随时修改数量，默认 1 个），默认每个索引 10 个 shard，5 个 primary shard，5 个 replica shard，最小的高可用配置，是 2 台服务器。

# 2.2. ElasticSearch 原理

# 2.2.1. ES 写数据过程

  • 客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node（协调节点）。
  • coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。
  • 实际的 node 上的 primary shard 处理请求，然后将数据同步到 replica node。
  • coordinating node 如果发现 primary node 和所有 replica node 都搞定之后，就返回响应结果给客户端。

es-write

# 2.2.2. es 读数据过程

可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。

  • 客户端发送请求到任意一个 node，成为 coordinate node。
  • coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin 随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。
  • 接收请求的 node 返回 document 给 coordinate node。
  • coordinate node 返回 document 给客户端。

# 2.2.3. 写数据底层原理

es-write-detail

先写入内存 buffer，在 buffer 里的时候数据是搜索不到的；同时将数据写入 translog 日志文件。

如果 buffer 快满了，或者到一定时间，就会将内存 buffer 数据 refresh 到一个新的 segment file 中，但是此时数据不是直接进入 segment file 磁盘文件，而是先进入 os cache 。这个过程就是 refresh。

每隔 1 秒钟，es 将 buffer 中的数据写入一个新的 segment file，每秒钟会产生一个新的磁盘文件 segment file，这个 segment file 中就存储最近 1 秒内 buffer 中写入的数据。

但是如果 buffer 里面此时没有数据，那当然不会执行 refresh 操作，如果 buffer 里面有数据，默认 1 秒钟执行一次 refresh 操作，刷入一个新的 segment file 中。

操作系统里面，磁盘文件其实都有一个东西，叫做 os cache，即操作系统缓存，就是说数据写入磁盘文件之前，会先进入 os cache，先进入操作系统级别的一个内存缓存中去。只要 buffer 中的数据被 refresh 操作刷入 os cache中，这个数据就可以被搜索到了。

为什么叫 es 是准实时的？ NRT，全称 near real-time。默认是每隔 1 秒 refresh 一次的，所以 es 是准实时的，因为写入的数据 1 秒之后才能被看到。可以通过 es 的 restful api 或者 java api，手动执行一次 refresh 操作，就是手动将 buffer 中的数据刷入 os cache中，让数据立马就可以被搜索到。只要数据被输入 os cache 中，buffer 就会被清空了，因为不需要保留 buffer 了，数据在 translog 里面已经持久化到磁盘去一份了。

重复上面的步骤，新的数据不断进入 buffer 和 translog，不断将 buffer 数据写入一个又一个新的 segment file 中去，每次 refresh 完 buffer 清空，translog 保留。随着这个过程推进，translog 会变得越来越大。当 translog 达到一定长度的时候，就会触发 commit 操作。

commit 操作发生第一步，就是将 buffer 中现有数据 refresh 到 os cache 中去，清空 buffer。然后，将一个 commit point 写入磁盘文件，里面标识着这个 commit point 对应的所有 segment file，同时强行将 os cache 中目前所有的数据都 fsync 到磁盘文件中去。最后清空 现有 translog 日志文件，重启一个 translog，此时 commit 操作完成。

这个 commit 操作叫做 flush。默认 30 分钟自动执行一次 flush，但如果 translog 过大，也会触发 flush。flush 操作就对应着 commit 的全过程，我们可以通过 es api，手动执行 flush 操作，手动将 os cache 中的数据 fsync 强刷到磁盘上去。

translog 日志文件的作用是什么？你执行 commit 操作之前，数据要么是停留在 buffer 中，要么是停留在 os cache 中，无论是 buffer 还是 os cache 都是内存，一旦这台机器死了，内存中的数据就全丢了。所以需要将数据对应的操作写入一个专门的日志文件 translog 中，一旦此时机器宕机，再次重启的时候，es 会自动读取 translog 日志文件中的数据，恢复到内存 buffer 和 os cache 中去。

translog 其实也是先写入 os cache 的，默认每隔 5 秒刷一次到磁盘中去，所以默认情况下，可能有 5 秒的数据会仅仅停留在 buffer 或者 translog 文件的 os cache 中，如果此时机器挂了，会丢失 5 秒钟的数据。但是这样性能比较好，最多丢 5 秒的数据。也可以将 translog 设置成每次写操作必须是直接 fsync 到磁盘，但是性能会差很多。

实际上你在这里，如果面试官没有问你 es 丢数据的问题，你可以在这里给面试官炫一把，你说，其实 es 第一是准实时的，数据写入 1 秒后可以搜索到；可能会丢失数据的。有 5 秒的数据，停留在 buffer、translog os cache、segment file os cache 中，而不在磁盘上，此时如果宕机，会导致 5 秒的数据丢失。

总结一下，数据先写入内存 buffer，然后每隔 1s，将数据 refresh 到 os cache，到了 os cache 数据就能被搜索到（所以我们才说 es 从写入到能被搜索到，中间有 1s 的延迟）。每隔 5s，将数据写入 translog 文件（这样如果机器宕机，内存数据全没，最多会有 5s 的数据丢失），translog 大到一定程度，或者默认每隔 30mins，会触发 commit 操作，将缓冲区的数据都 flush 到 segment file 磁盘文件中。

数据写入 segment file 之后，同时就建立好了倒排索引。

# 2.2.4. 删除/更新数据底层原理

如果是删除操作，commit 的时候会生成一个 .del 文件，里面将某个 doc 标识为 deleted 状态，那么搜索的时候根据 .del 文件就知道这个 doc 是否被删除了。

如果是更新操作，就是将原来的 doc 标识为 deleted 状态，然后新写入一条数据。

buffer 每 refresh 一次，就会产生一个 segment file，所以默认情况下是 1 秒钟一个 segment file，这样下来 segment file 会越来越多，此时会定期执行 merge。每次 merge 的时候，会将多个 segment file 合并成一个，同时这里会将标识为 deleted 的 doc 给物理删除掉，然后将新的 segment file 写入磁盘，这里会写一个 commit point，标识所有新的 segment file，然后打开 segment file 供搜索使用，同时删除旧的 segment file。

# 2.2.5. 底层 lucene

简单来说，lucene 就是一个 jar 包，里面包含了封装好的各种建立倒排索引的算法代码。我们用 Java 开发的时候，引入 lucene jar，然后基于 lucene 的 api 去开发就可以了。

通过 lucene，我们可以将已有的数据建立索引，lucene 会在本地磁盘上面，给我们组织索引的数据结构。

# 2.2.6. 倒排索引

在搜索引擎中，每个文档都有一个对应的文档 ID，文档内容被表示为一系列关键词的集合。例如，文档 1 经过分词，提取了 20 个关键词，每个关键词都会记录它在文档中出现的次数和出现位置。

那么，倒排索引就是关键词到文档 ID 的映射，每个关键词都对应着一系列的文件，这些文件中都出现了关键词。

举个栗子。

有以下文档：

DocId Doc
1 谷歌地图之父跳槽 Facebook
2 谷歌地图之父加盟 Facebook
3 谷歌地图创始人拉斯离开谷歌加盟 Facebook
4 谷歌地图之父跳槽 Facebook 与 Wave 项目取消有关
5 谷歌地图之父拉斯加盟社交网站 Facebook

对文档进行分词之后，得到以下倒排索引。

WordId Word DocIds
1 谷歌 1,2,3,4,5
2 地图 1,2,3,4,5
3 之父 1,2,4,5
4 跳槽 1,4
5 Facebook 1,2,3,4,5
6 加盟 2,3,5
7 创始人 3
8 拉斯 3,5
9 离开 3
10 与 4
.. .. ..

另外，实用的倒排索引还可以记录更多的信息，比如文档频率信息，表示在文档集合中有多少个文档包含某个单词。

那么，有了倒排索引，搜索引擎可以很方便地响应用户的查询。比如用户输入查询 Facebook，搜索系统查找倒排索引，从中读出包含这个单词的文档，这些文档就是提供给用户的搜索结果。

要注意倒排索引的两个重要细节：

  • 倒排索引中的所有词项对应一个或多个文档；
  • 倒排索引中的词项根据字典顺序升序排列

上面只是一个简单的栗子，并没有严格按照字典顺序升序排列。

# 3. Logstash

Logstash (opens new window) 是开源的服务器端数据处理管道，能够同时从多个来源采集数据，转换数据，然后将数据发送到您最喜欢的“存储库”中。

# 3.1. Logstash 简介

Logstash 可以传输和处理你的日志、事务或其他数据。

Logstash 是 Elasticsearch 的最佳数据管道。

Logstash 是插件式管理模式，在输入、过滤、输出以及编码过程中都可以使用插件进行定制。Logstash 社区有超过 200 种可用插件。

# 3.2. Logstash 原理

Logstash 有两个必要元素：input 和 output ，一个可选元素：filter。

这三个元素，分别代表 Logstash 事件处理的三个阶段：输入 > 过滤器 > 输出。

img

  • input - 负责从数据源采集数据。
  • filter - 将数据修改为你指定的格式或内容。
  • output - 将数据传输到目的地。

在实际应用场景中，通常输入、输出、过滤器不止一个。Logstash 的这三个元素都使用插件式管理方式，用户可以根据应用需要，灵活的选用各阶段需要的插件，并组合使用。

# 4. Beats

Beats (opens new window) 是安装在服务器上的数据中转代理。

Beats 可以将数据直接传输到 Elasticsearch 或传输到 Logstash 。

img

Beats 有多种类型，可以根据实际应用需要选择合适的类型。

常用的类型有：

  • **Packetbeat：**网络数据包分析器，提供有关您的应用程序服务器之间交换的事务的信息。
  • **Filebeat：**从您的服务器发送日志文件。
  • **Metricbeat：**是一个服务器监视代理程序，它定期从服务器上运行的操作系统和服务收集指标。
  • **Winlogbeat：**提供 Windows 事件日志。

# 4.1. Filebeat 简介

由于本人仅接触过 Filebeat，所以本文只介绍 Beats 组件中的 Filebeat。

相比 Logstash，FileBeat 更加轻量化。

在任何环境下，应用程序都有停机的可能性。 Filebeat 读取并转发日志行，如果中断，则会记住所有事件恢复联机状态时所在位置。

Filebeat 带有内部模块（auditd，Apache，Nginx，System 和 MySQL），可通过一个指定命令来简化通用日志格式的收集，解析和可视化。

FileBeat 不会让你的管道超负荷。FileBeat 如果是向 Logstash 传输数据，当 Logstash 忙于处理数据，会通知 FileBeat 放慢读取速度。一旦拥塞得到解决，FileBeat 将恢复到原来的速度并继续传播。

img

# 4.2. Filebeat 原理

Filebeat 有两个主要组件：

  • harvester：负责读取一个文件的内容。它会逐行读取文件内容，并将内容发送到输出目的地。
  • prospector：负责管理 harvester 并找到所有需要读取的文件源。比如类型是日志，prospector 就会遍历制定路径下的所有匹配要求的文件。
filebeat.prospectors:
+  - type: log
+    paths:
+      - /var/log/*.log
+      - /var/path2/*.log
+

Filebeat 保持每个文件的状态，并经常刷新注册表文件中的磁盘状态。状态用于记住 harvester 正在读取的最后偏移量，并确保发送所有日志行。

Filebeat 将每个事件的传递状态存储在注册表文件中。所以它能保证事件至少传递一次到配置的输出，没有数据丢失。

# 5. 运维

# 6. 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elastic
上次更新: 2023/06/29, 22:27:04
Elasticsearch 运维
Elastic 技术栈之 Filebeat

+ ← + Elastic 技术栈之 Filebeat→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/55ce99/index.html b/pages/55ce99/index.html new file mode 100644 index 00000000..905b6839 --- /dev/null +++ b/pages/55ce99/index.html @@ -0,0 +1,186 @@ + + + + + + Elastic 技术栈之 Logstash | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-16
目录

Elastic 技术栈之 Logstash

# Elastic 技术栈之 Logstash

本文是 Elastic 技术栈（ELK）的 Logstash 应用。

如果不了解 Elastic 的安装、配置、部署，可以参考：Elastic 技术栈之快速入门 (opens new window)

# 简介

Logstash 可以传输和处理你的日志、事务或其他数据。

# 功能

Logstash 是 Elasticsearch 的最佳数据管道。

Logstash 是插件式管理模式，在输入、过滤、输出以及编码过程中都可以使用插件进行定制。Logstash 社区有超过 200 种可用插件。

# 工作原理

Logstash 有两个必要元素：input 和 output ，一个可选元素：filter。

这三个元素，分别代表 Logstash 事件处理的三个阶段：输入 > 过滤器 > 输出。

img

  • input 负责从数据源采集数据。
  • filter 将数据修改为你指定的格式或内容。
  • output 将数据传输到目的地。

在实际应用场景中，通常输入、输出、过滤器不止一个。Logstash 的这三个元素都使用插件式管理方式，用户可以根据应用需要，灵活的选用各阶段需要的插件，并组合使用。

后面将对插件展开讲解，暂且不表。

# 设置

# 设置文件

  • logstash.yml：logstash 的默认启动配置文件
  • jvm.options：logstash 的 JVM 配置文件。
  • startup.options (Linux)：包含系统安装脚本在 /usr/share/logstash/bin 中使用的选项为您的系统构建适当的启动脚本。安装 Logstash 软件包时，系统安装脚本将在安装过程结束时执行，并使用 startup.options 中指定的设置来设置用户，组，服务名称和服务描述等选项。

# logstash.yml 设置项

节选部分设置项，更多项请参考：https://www.elastic.co/guide/en/logstash/current/logstash-settings-file.html (opens new window)

参数 描述 默认值
node.name 节点名 机器的主机名
path.data Logstash 及其插件用于任何持久性需求的目录。 LOGSTASH_HOME/data
pipeline.workers 同时执行管道的过滤器和输出阶段的工作任务数量。如果发现事件正在备份，或 CPU 未饱和，请考虑增加此数字以更好地利用机器处理能力。 Number of the host’s CPU cores
pipeline.batch.size 尝试执行过滤器和输出之前，单个工作线程从输入收集的最大事件数量。较大的批量处理大小一般来说效率更高，但是以增加的内存开销为代价。您可能必须通过设置 LS_HEAP_SIZE 变量来有效使用该选项来增加 JVM 堆大小。 125
pipeline.batch.delay 创建管道事件批处理时，在将一个尺寸过小的批次发送给管道工作任务之前，等待每个事件需要多长时间（毫秒）。 5
pipeline.unsafe_shutdown 如果设置为 true，则即使在内存中仍存在 inflight 事件时，也会强制 Logstash 在关闭期间退出。默认情况下，Logstash 将拒绝退出，直到所有接收到的事件都被推送到输出。启用此选项可能会导致关机期间数据丢失。 false
path.config 主管道的 Logstash 配置路径。如果您指定一个目录或通配符，配置文件将按字母顺序从目录中读取。 Platform-specific. See [dir-layout] (opens new window).
config.string 包含用于主管道的管道配置的字符串。使用与配置文件相同的语法。 None
config.test_and_exit 设置为 true 时，检查配置是否有效，然后退出。请注意，使用此设置不会检查 grok 模式的正确性。 Logstash 可以从目录中读取多个配置文件。如果将此设置与 log.level：debug 结合使用，则 Logstash 将记录组合的配置文件，并注掉其源文件的配置块。 false
config.reload.automatic 设置为 true 时，定期检查配置是否已更改，并在配置更改时重新加载配置。这也可以通过 SIGHUP 信号手动触发。 false
config.reload.interval Logstash 检查配置文件更改的时间间隔。 3s
config.debug 设置为 true 时，将完全编译的配置显示为调试日志消息。您还必须设置log.level：debug。警告：日志消息将包括任何传递给插件配置作为明文的“密码”选项，并可能导致明文密码出现在您的日志！ false
config.support_escapes 当设置为 true 时，带引号的字符串将处理转义字符。 false
modules 配置时，模块必须处于上表所述的嵌套 YAML 结构中。 None
http.host 绑定地址 "127.0.0.1"
http.port 绑定端口 9600
log.level 日志级别。有效选项：fatal > error > warn > info > debug > trace info
log.format 日志格式。json （JSON 格式）或 plain （原对象） plain
path.logs Logstash 自身日志的存储路径 LOGSTASH_HOME/logs
path.plugins 在哪里可以找到自定义的插件。您可以多次指定此设置以包含多个路径。

# 启动

# 命令行

通过命令行启动 logstash 的方式如下：

bin/logstash [options]
+

其中 options 是您可以指定用于控制 Logstash 执行的命令行标志。

在命令行上设置的任何标志都会覆盖 Logstash 设置文件（logstash.yml）中的相应设置，但设置文件本身不会更改。

注

虽然可以通过指定命令行参数的方式，来控制 logstash 的运行方式，但显然这么做很麻烦。

建议通过指定配置文件的方式，来控制 logstash 运行，启动命令如下：

bin/logstash -f logstash.conf
+

若想了解更多的命令行参数细节，请参考：https://www.elastic.co/guide/en/logstash/current/running-logstash-command-line.html (opens new window)

# 配置文件

上节，我们了解到，logstash 可以执行 bin/logstash -f logstash.conf ，按照配置文件中的参数去覆盖默认设置文件（logstash.yml）中的设置。

这节，我们就来学习一下这个配置文件如何配置参数。

# 配置文件结构

在工作原理一节中，我们已经知道了 Logstash 主要有三个工作阶段 input 、filter、output。而 logstash 配置文件文件结构也与之相对应：

input {}
+
+filter {}
+
+output {}
+

每个部分都包含一个或多个插件的配置选项。如果指定了多个过滤器，则会按照它们在配置文件中的显示顺序应用它们。

# 插件配置

插件的配置由插件名称和插件的一个设置块组成。

下面的例子中配置了两个输入文件配置：

input {
+  file {
+    path => "/var/log/messages"
+    type => "syslog"
+  }
+
+  file {
+    path => "/var/log/apache/access.log"
+    type => "apache"
+  }
+}
+

您可以配置的设置因插件类型而异。你可以参考： Input Plugins (opens new window), Output Plugins (opens new window), Filter Plugins (opens new window), 和 Codec Plugins (opens new window) 。

# 值类型

一个插件可以要求设置的值是一个特定的类型，比如布尔值，列表或哈希值。以下值类型受支持。

  • Array
  users => [ {id => 1, name => bob}, {id => 2, name => jane} ]
+
  • Lists
path => ['/var/log/messages', '/var/log/*.log']
+uris => ['http://elastic.co', 'http://example.net']
+
  • Boolean
ssl_enable => true
+
  • Bytes
  my_bytes => "1113"   # 1113 bytes
+  my_bytes => "10MiB"  # 10485760 bytes
+  my_bytes => "100kib" # 102400 bytes
+  my_bytes => "180 mb" # 180000000 bytes
+
  • Codec
codec => 'json'
+
  • Hash
match => {
+  "field1" => "value1"
+  "field2" => "value2"
+  ...
+}
+
  • Number
port => 33
+
  • Password
my_password => 'password'
+
  • URI
my_uri => 'http://foo:bar@example.net'
+
  • Path
my_path => '/tmp/logstash'
+

  • String

  • 转义字符

# 插件

# input

Logstash 支持各种输入选择 ，可以在同一时间从众多常用来源捕捉事件。能够以连续的流式传输方式，轻松地从您的日志、指标、Web 应用、数据存储以及各种 AWS 服务采集数据。

# 常用 input 插件

  • file：从文件系统上的文件读取，就像 UNIX 命令 tail -0F 一样
  • **syslog：**在众所周知的端口 514 上侦听系统日志消息，并根据 RFC3164 格式进行解析
  • **redis：**从 redis 服务器读取，使用 redis 通道和 redis 列表。 Redis 经常用作集中式 Logstash 安装中的“代理”，它将来自远程 Logstash“托运人”的 Logstash 事件排队。
  • **beats：**处理由 Filebeat 发送的事件。

更多详情请见：Input Plugins (opens new window)

# filter

过滤器是 Logstash 管道中的中间处理设备。如果符合特定条件，您可以将条件过滤器组合在一起，对事件执行操作。

# 常用 filter 插件

  • **grok：**解析和结构任意文本。 Grok 目前是 Logstash 中将非结构化日志数据解析为结构化和可查询的最佳方法。
  • **mutate：**对事件字段执行一般转换。您可以重命名，删除，替换和修改事件中的字段。
  • **drop：**完全放弃一个事件，例如调试事件。
  • **clone：**制作一个事件的副本，可能会添加或删除字段。
  • **geoip：**添加有关 IP 地址的地理位置的信息（也可以在 Kibana 中显示惊人的图表！）

更多详情请见：Filter Plugins (opens new window)

# output

输出是 Logstash 管道的最后阶段。一个事件可以通过多个输出，但是一旦所有输出处理完成，事件就完成了执行。

# 常用 output 插件

  • **elasticsearch：**将事件数据发送给 Elasticsearch（推荐模式）。
  • **file：**将事件数据写入文件或磁盘。
  • **graphite：**将事件数据发送给 graphite（一个流行的开源工具，存储和绘制指标。 http://graphite.readthedocs.io/en/latest/）。 (opens new window)
  • **statsd：**将事件数据发送到 statsd （这是一种侦听统计数据的服务，如计数器和定时器，通过 UDP 发送并将聚合发送到一个或多个可插入的后端服务）。

更多详情请见：Output Plugins (opens new window)

# codec

用于格式化对应的内容。

# 常用 codec 插件

  • **json：**以 JSON 格式对数据进行编码或解码。
  • **multiline：**将多行文本事件（如 java 异常和堆栈跟踪消息）合并为单个事件。

更多插件请见：Codec Plugins (opens new window)

# 实战

前面的内容都是对 Logstash 的介绍和原理说明。接下来，我们来实战一些常见的应用场景。

# 传输控制台数据

stdin input 插件从标准输入读取事件。这是最简单的 input 插件，一般用于测试场景。

应用

（1）创建 logstash-input-stdin.conf ：

input { stdin { } }
+output {
+  elasticsearch { hosts => ["localhost:9200"] }
+  stdout { codec => rubydebug }
+}
+

更多配置项可以参考：https://www.elastic.co/guide/en/logstash/current/plugins-inputs-stdin.html (opens new window)

（2）执行 logstash，使用 -f 来指定你的配置文件：

bin/logstash -f logstash-input-stdin.conf
+

# 传输 logback 日志

elk 默认使用的 Java 日志工具是 log4j2 ，并不支持 logback 和 log4j。

想使用 logback + logstash ，可以使用 logstash-logback-encoder (opens new window) 。logstash-logback-encoder (opens new window) 提供了 UDP / TCP / 异步方式来传输日志数据到 logstash。

如果你使用的是 log4j ，也不是不可以用这种方式，只要引入桥接 jar 包即可。如果你对 log4j 、logback ，或是桥接 jar 包不太了解，可以参考我的这篇博文：细说 Java 主流日志工具库 (opens new window) 。

# TCP 应用

logstash 配置

（1）创建 logstash-input-tcp.conf ：

input {
+tcp {
+  port => 9251
+  codec => json_lines
+  mode => server
+}
+}
+output {
+ elasticsearch { hosts => ["localhost:9200"] }
+ stdout { codec => rubydebug }
+}
+

更多配置项可以参考：https://www.elastic.co/guide/en/logstash/current/plugins-inputs-tcp.html (opens new window)

（2）执行 logstash，使用 -f 来指定你的配置文件：bin/logstash -f logstash-input-udp.conf

java 应用配置

（1）在 Java 应用的 pom.xml 中引入 jar 包：

<dependency>
+ <groupId>net.logstash.logback</groupId>
+ <artifactId>logstash-logback-encoder</artifactId>
+ <version>4.11</version>
+</dependency>
+
+<!-- logback 依赖包 -->
+<dependency>
+ <groupId>ch.qos.logback</groupId>
+ <artifactId>logback-core</artifactId>
+ <version>1.2.3</version>
+</dependency>
+<dependency>
+ <groupId>ch.qos.logback</groupId>
+ <artifactId>logback-classic</artifactId>
+ <version>1.2.3</version>
+</dependency>
+<dependency>
+ <groupId>ch.qos.logback</groupId>
+ <artifactId>logback-access</artifactId>
+ <version>1.2.3</version>
+</dependency>
+

（2）接着，在 logback.xml 中添加 appender

<appender name="ELK-TCP" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
+ <!--
+ destination 是 logstash 服务的 host:port，
+ 相当于和 logstash 建立了管道，将日志数据定向传输到 logstash
+ -->
+ <destination>192.168.28.32:9251</destination>
+ <encoder charset="UTF-8" class="net.logstash.logback.encoder.LogstashEncoder"/>
+</appender>
+<logger name="io.github.dunwu.spring" level="TRACE" additivity="false">
+ <appender-ref ref="ELK-TCP" />
+</logger>
+

（3）接下来，就是 logback 的具体使用 ，如果对此不了解，不妨参考一下我的这篇博文：细说 Java 主流日志工具库 (opens new window) 。

实例：我的 logback.xml (opens new window)

# UDP 应用

UDP 和 TCP 的使用方式大同小异。

logstash 配置

（1）创建 logstash-input-udp.conf ：

input {
+udp {
+  port => 9250
+  codec => json
+}
+}
+output {
+ elasticsearch { hosts => ["localhost:9200"] }
+ stdout { codec => rubydebug }
+}
+

更多配置项可以参考：https://www.elastic.co/guide/en/logstash/current/plugins-inputs-udp.html (opens new window)

（2）执行 logstash，使用 -f 来指定你的配置文件：bin/logstash -f logstash-input-udp.conf

java 应用配置

（1）在 Java 应用的 pom.xml 中引入 jar 包：

与 TCP 应用 一节中的引入依赖包完全相同。

（2）接着，在 logback.xml 中添加 appender

<appender name="ELK-UDP" class="net.logstash.logback.appender.LogstashSocketAppender">
+  <host>192.168.28.32</host>
+  <port>9250</port>
+</appender>
+<logger name="io.github.dunwu.spring" level="TRACE" additivity="false">
+  <appender-ref ref="ELK-UDP" />
+</logger>
+

（3）接下来，就是 logback 的具体使用 ，如果对此不了解，不妨参考一下我的这篇博文：细说 Java 主流日志工具库 (opens new window) 。

实例：我的 logback.xml (opens new window)

# 传输文件

在 Java Web 领域，需要用到一些重要的工具，例如 Tomcat 、Nginx 、Mysql 等。这些不属于业务应用，但是它们的日志数据对于定位问题、分析统计同样很重要。这时无法使用 logback 方式将它们的日志传输到 logstash。

如何采集这些日志文件呢？别急，你可以使用 logstash 的 file input 插件。

需要注意的是，传输文件这种方式，必须在日志所在的机器上部署 logstash 。

应用

logstash 配置

（1）创建 logstash-input-file.conf ：

input {
+ file {
+  path => ["/var/log/nginx/access.log"]
+  type => "nginx-access-log"
+  start_position => "beginning"
+ }
+}
+
+output {
+ if [type] == "nginx-access-log" {
+  elasticsearch {
+   hosts => ["localhost:9200"]
+   index => "nginx-access-log"
+  }
+ }
+}
+

（2）执行 logstash，使用 -f 来指定你的配置文件：bin/logstash -f logstash-input-file.conf

更多配置项可以参考：https://www.elastic.co/guide/en/logstash/current/plugins-inputs-file.html (opens new window)

# 小技巧

# 启动、终止应用

如果你的 logstash 每次都是通过指定配置文件方式启动。不妨建立一个启动脚本。

# cd xxx 进入 logstash 安装目录下的 bin 目录
+logstash -f logstash.conf
+

如果你的 logstash 运行在 linux 系统下，不妨使用 nohup 来启动一个守护进程。这样做的好处在于，即使关闭终端，应用仍会运行。

创建 startup.sh

nohup ./logstash -f logstash.conf >> nohup.out 2>&1 &
+

终止应用没有什么好方法，你只能使用 ps -ef | grep logstash ，查出进程，将其 kill 。不过，我们可以写一个脚本来干这件事：

创建 shutdown.sh

脚本不多解释，请自行领会作用。

PID=`ps -ef | grep logstash | awk '{ print $2}' | head -n 1`
+kill -9 ${PID}
+

# 资料

# 推荐阅读

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elastic#Logstash
上次更新: 2023/06/29, 22:27:04
Kibana 运维
Logstash 运维

+ ← + Logstash 运维→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/55e9a7/index.html b/pages/55e9a7/index.html new file mode 100644 index 00000000..fac06d9b --- /dev/null +++ b/pages/55e9a7/index.html @@ -0,0 +1,84 @@ + + + + + + 扩展 SQL | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-10-10
目录

扩展 SQL

# 扩展 SQL

# 数据库

# 表

# 查看表的基本信息

SELECT * FROM information_schema.tables
+WHERE table_schema = 'test' AND table_name = 'user';
+

# 查看表的列信息

SELECT * FROM information_schema.columns
+WHERE table_schema = 'test' AND table_name = 'user';
+

# 如何批量删除大量数据

如果要根据时间范围批量删除大量数据，最简单的语句如下：

delete from orders
+where timestamp < SUBDATE(CURDATE(),INTERVAL 3 month);
+

上面的语句，大概率执行会报错，提示删除失败，因为需要删除的数据量太大了，所以需要分批删除。

可以先通过一次查询，找到符合条件的历史订单中最大的那个订单 ID，然后在删除语句中把删除的条件转换成按主键删除。

select max(id) from orders
+where timestamp < SUBDATE(CURDATE(),INTERVAL 3 month);
+
+-- 分批删除，? 填上一条语句查到的最大 ID
+delete from orders
+where id <= ?
+order by id limit 1000;
+

# 修改表的编码格式

utf8mb4 编码是 utf8 编码的超集，兼容 utf8，并且能存储 4 字节的表情字符。如果表的编码指定为 utf8，在保存 emoji 字段时会报错。

ALTER TABLE <tableName> CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
+

# 其他

# 显示哪些线程正在运行

mysql> show processlist;
++----+-----------------+-----------------+------+---------+-------+------------------------+------------------+
+| Id | User            | Host            | db   | Command | Time  | State                  | Info             |
++----+-----------------+-----------------+------+---------+-------+------------------------+------------------+
+|  5 | event_scheduler | localhost       | NULL | Daemon  | 40230 | Waiting on empty queue | NULL             |
+| 10 | root            | localhost:10120 | NULL | Query   |     0 | init                   | show processlist |
++----+-----------------+-----------------+------+---------+-------+------------------------+------------------+
+2 rows in set (0.00 sec)
+

Mysql 连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 show processlist 命令中看到它。其中的 Command 列显示为“Sleep”的这一行，就表示现在系统里面有一个空闲连接。客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#SQL
上次更新: 2023/06/29, 22:27:04
SQL 语法基础特性
SQL Cheat Sheet

+ ← + SQL Cheat Sheet→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/562f99/index.html b/pages/562f99/index.html new file mode 100644 index 00000000..adf91b51 --- /dev/null +++ b/pages/562f99/index.html @@ -0,0 +1,183 @@ + + + + + + MongoDB 建模 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-09
目录

MongoDB 建模

# MongoDB 建模

MongoDB 的数据模式是一种灵活模式，关系型数据库要求你在插入数据之前必须先定义好一个表的模式结构，而 MongoDB 的集合则并不限制 document 结构。这种灵活性让对象和数据库文档之间的映射变得很容易。即使数据记录之间有很大的变化，每个文档也可以很好的映射到各条不同的记录。 当然在实际使用中，同一个集合中的文档往往都有一个比较类似的结构。

数据模型设计中最具挑战性的是在应用程序需求，数据库引擎性能要求和数据读写模式之间做权衡考量。当设计数据模型的时候，一定要考虑应用程序对数据的使用模式（如查询，更新和处理）以及数据本身的天然结构。

# MongoDB 数据建模入门

参考：https://docs.mongodb.com/guides/server/introduction/#what-you-ll-need

# （一）定义数据集

当需要建立数据存储时，首先应该思考以下问题：需要存储哪些数据？这些字段之间如何关联？

这是一个数据建模的过程。目标是将业务需求抽象为逻辑模型。

假设这样一个场景：我们需要建立数据库以跟踪物料及其数量，大小，标签和等级。

如果是存储在 RDBMS，可能以下的数据表：

name quantity size status tags rating
journal 25 14x21,cm A brown, lined 9
notebook 50 8.5x11,in A college-ruled,perforated 8
paper 100 8.5x11,in D watercolor 10
planner 75 22.85x30,cm D 2019 10
postcard 45 10x,cm D double-sided,white 2

# （二）思考 JSON 结构

从上例中可以看出，表似乎是存储数据的好地方，但该数据集中的字段需要多个值，如果在单个列中建模，则不容易搜索或显示（对于 例如–大小和标签）。

在 SQL 数据库中，您可以通过创建关系表来解决此问题。

在 MongoDB 中，数据存储为文档（document）。 这些文档以 JSON（JavaScript 对象表示法）格式存储在 MongoDB 中。 JSON 文档支持嵌入式字段，因此相关数据和数据列表可以与文档一起存储，而不是与外部表一起存储。

JSON 格式为键/值对。 在 JSON 文档中，字段名和值用冒号分隔，字段名和值对用逗号分隔，并且字段集封装在“大括号”（{}）中。

如果要开始对上面的行之一进行建模，例如此行：

name quantity size status tags rating
notebook 50 8.5x11,in A college-ruled,perforated 8

您可以从 name 和 quantity 字段开始。 在 JSON 中，这些字段如下所示：

{ "name": "notebook", "qty": 50 }
+

# （三）确定哪些字段作为嵌入式数据

接下来，需要确定哪些字段可能需要多个值。可以考虑将这些字段作为嵌入式文档或嵌入式文档中的 列表/数组 对象。

例如，在上面的示例中，size 可能包含三个字段：

{ "h": 11, "w": 8.5, "uom": "in" }
+

And some items have multiple ratings, so ratings might be represented as a list of documents containing the field scores:

[{ "score": 8 }, { "score": 9 }]
+

And you might need to handle multiple tags per item. So you might store them in a list too.

["college-ruled", "perforated"]
+

Finally, a JSON document that stores an inventory item might look like this:

{
+  "name": "notebook",
+  "qty": 50,
+  "rating": [{ "score": 8 }, { "score": 9 }],
+  "size": { "height": 11, "width": 8.5, "unit": "in" },
+  "status": "A",
+  "tags": ["college-ruled", "perforated"]
+}
+

This looks very different from the tabular data structure you started with in Step 1.

# 数据模型简介

数据建模中的关键挑战是平衡应用程序的需求、数据库引擎的性能以及数据检索模式。 在设计数据模型时，始终需要考虑数据的应用程序使用情况（即数据的查询，更新和处理）以及数据本身的固有结构。

# 灵活的 Schema

在关系型数据库中，必须在插入数据之前确定并声明表的结构。而 MongoDB 的 collection 默认情况下不需要其文档具有相同的架构。也就是说：

同一个 collection 中的 document 不需要具有相同的 field 集，并且 field 的数据类型可以在集合中的不同文档之间有所不同。

要更改 collection 中的 document 结构，例如添加新 field，删除现有 field 或将 field 值更改为新类型，只需要将文档更新为新结构即可。

这种灵活性有助于将 document 映射到实体或对象。每个 document 都可以匹配所表示实体的数据字段，即使该文档与集合中的其他文档有很大的不同。但是，实际上，集合中的文档具有相似的结构，并且您可以在更新和插入操作期间对 collection 强制执行 document 校验规则。

# Document 结构

# 嵌入式数据模型

嵌入式 document 通过将相关数据存储在单个 document 结构中来捕获数据之间的关系。 MongoDB document 可以将 document 结构嵌入到另一个 document 中的字段或数组中。这些非规范化的数据模型允许应用程序在单个数据库操作中检索和操纵相关数据。

img

对于 MongoDB 中的很多场景，非规范化数据模型都是最佳的。

嵌入式 document 有大小限制：必须小于 16 MB。

如果是较大的二进制数据，可以考虑 GridFS (opens new window)。

# 引用式数据模型

引用通过包含从一个 document 到另一个 document 的链接或引用来存储数据之间的关系。 应用程序可以解析这些引用以访问相关数据。 广义上讲，这些是规范化的数据模型。

img

通常，在以下场景使用引用式的数据模型：

  • 嵌入时会导致数据重复，但无法提供足够的读取性能优势，无法胜过重复的含义。
  • 代表更复杂的多对多关系。
  • 为大规模分层数据集建模。

为了 join collection，MongoDB 支持聚合 stage：

MongoDB 还提供了引用来支持跨集合 join 数据：

# 原子写操作

# 单 document 的原子性

在 MongoDB 中，针对单个 document 的写操作是原子性的，即使该 document 中嵌入了多个子 document。 具有嵌入数据的非规范化数据模型将所有相关数据合并在一个 document 中，而不是在多个 document 和 collection 中进行规范化。 该数据模型有助于原子操作。 当单个写入操作（例如 db.collection.updateMany() (opens new window)）修改多个 document 时，每个 document 的独立修改是原子的，但整个操作不是原子的。

# 多 document 事务

对于需要对多个 document（在单个或多个集合中）进行读写原子性的情况，MongoDB 支持多 document 事务。

  • 在版本 4.0 中，MongoDB 在副本集上支持多 document 事务。
  • 在版本 4.2 中，MongoDB 引入了分布式事务，它增加了对分片群集上多 document 事务的支持，并合并了对副本集上多 document 事务的现有支持。

在大多数情况下，多 document 事务会比单 document 的写入产生更高的性能消耗，并且多 document 事务的可用性不能替代高效的结构设计。 在许多情况下，非规范化数据模型（嵌入式 document 和数组）仍是最佳选择。 也就是说，合理的数据建模，将最大程度地减少对多 document 事务的需求。

# 数据使用和性能

在设计数据模型时，请考虑应用程序将如何使用您的数据库。 例如，如果您的应用程序仅使用最近插入的 document，请考虑使用上限集合。 或者，如果您的应用程序主要是对 collection 的读取操作，则添加索引以提高性能。

# Schema 校验

# 指定校验规则

如果创建新 collection 时要指定校验规则，需要在使用 db.createCollection() (opens new window) 时指定 validator 选项。

如果要将 document 校验添加到现有 collection 中，需要使用带有 validator 选项的 collMod (opens new window) 命令。

MongoDB 还提供以下相关选项：

  • validationLevel 选项（用于确定 MongoDB 在更新过程中，对现有 document 应用校验规则的严格程度）
  • validationAction 选项（用于确定 MongoDB 发现违反校验规则的 document 时，是选择报错并拒绝，还是接受数据但在日志中告警）。

# JSON Schema

从 3.6 版本开始，MongoDB 开始支持 JSON Schema 校验。

可以通过在 validator 表达式中使用 $jsonSchema (opens new window) 操作来指定 JSON Schema 校验。

【示例】

db.createCollection('students', {
+  validator: {
+    $jsonSchema: {
+      bsonType: 'object',
+      required: ['name', 'year', 'major', 'address'],
+      properties: {
+        name: {
+          bsonType: 'string',
+          description: 'must be a string and is required'
+        },
+        year: {
+          bsonType: 'int',
+          minimum: 2017,
+          maximum: 3017,
+          description: 'must be an integer in [ 2017, 3017 ] and is required'
+        },
+        major: {
+          enum: ['Math', 'English', 'Computer Science', 'History', null],
+          description: 'can only be one of the enum values and is required'
+        },
+        gpa: {
+          bsonType: ['double'],
+          description: 'must be a double if the field exists'
+        },
+        address: {
+          bsonType: 'object',
+          required: ['city'],
+          properties: {
+            street: {
+              bsonType: 'string',
+              description: 'must be a string if the field exists'
+            },
+            city: {
+              bsonType: 'string',
+              description: 'must be a string and is required'
+            }
+          }
+        }
+      }
+    }
+  }
+})
+

# 其它查询表达式

除了使用 $jsonSchema (opens new window) 查询运算符的 JSON Schema 校验外，MongoDB 还支持其它查询运算符的校验，但以下情况除外：

【示例】查询表达式中指定校验规则

db.createCollection('contacts', {
+  validator: {
+    $or: [
+      { phone: { $type: 'string' } },
+      { email: { $regex: /@mongodb\.com$/ } },
+      { status: { $in: ['Unknown', 'Incomplete'] } }
+    ]
+  }
+})
+

# 行为

校验发生在更新和插入期间。添加校验规则到 collection 时，不会对现有的 document 进行校验，除非发生修改操作。

# 现有的 document

validationLevel 选项确定 MongoDB 进行规则校验时执行的操作：

  • 如果 validationLevel 是 strict（严格级别。这是 MongoDB 默认级别），则 MongoDB 将校验规则应用于所有插入和更新。
  • 如果 validationLevel 是 moderate（中等级别），则 MongoDB 只对已满足校验条件的现有文档的插入和更新操作进行校验；对不符合校验标准的现有文档的更新操作不进行校验。

【示例】

下面是一个正常的插入操作：

db.contacts.insert([
+  {
+    _id: 1,
+    name: 'Anne',
+    phone: '+1 555 123 456',
+    city: 'London',
+    status: 'Complete'
+  },
+  { _id: 2, name: 'Ivan', city: 'Vancouver' }
+])
+

在 collection 上配置一个校验规则：

db.runCommand({
+  collMod: 'contacts',
+  validator: {
+    $jsonSchema: {
+      bsonType: 'object',
+      required: ['phone', 'name'],
+      properties: {
+        phone: {
+          bsonType: 'string',
+          description: 'must be a string and is required'
+        },
+        name: {
+          bsonType: 'string',
+          description: 'must be a string and is required'
+        }
+      }
+    }
+  },
+  validationLevel: 'moderate'
+})
+

则 contacts collection 现在添加了含中等级别（moderate） validationLevel 的 validator：

  • 如果尝试更新 _id为 1 的文档，则 MongoDB 将应用校验规则，因为现有文档符合条件。

  • 相反，MongoDB 不会将校验 _id 为 2 的文档，因为它不符合校验规则。

如果要完全禁用校验，可以将 validationLevel 置为 off。

# 接受或拒绝无效的 document

  • 如果 validationAction 是 Error（默认），则 MongoDB 拒绝任何违反校验规则的插入或更新。
  • 如果 validationAction 是 Warn，MongoDB 会记录所有的违规，但允许进行插入或更新。

【示例】

创建集合时，配置 validationAction 为 warn。

db.createCollection('contacts2', {
+  validator: {
+    $jsonSchema: {
+      bsonType: 'object',
+      required: ['phone'],
+      properties: {
+        phone: {
+          bsonType: 'string',
+          description: 'must be a string and is required'
+        },
+        email: {
+          bsonType: 'string',
+          pattern: '@mongodb.com$',
+          description:
+            'must be a string and match the regular expression pattern'
+        },
+        status: {
+          enum: ['Unknown', 'Incomplete'],
+          description: 'can only be one of the enum values'
+        }
+      }
+    }
+  },
+  validationAction: 'warn'
+})
+

尝试插入一条违规记录

> db.contacts2.insert( { name: "Amanda", status: "Updated" } )
+WriteResult({ "nInserted" : 1 })
+

MongoDB 允许这条操作执行，但是服务器会记录下告警信息。

{"t":{"$date":"2020-09-11T16:35:57.754+08:00"},"s":"W",  "c":"STORAGE",  "id":20294,   "ctx":"conn14","msg":"Document would fail validation","attr":{"namespace":"test.contacts2","document":{"_id":{"$oid":"5f5b36ed8ea53d62a0b51c4e"},"name":"Amanda","status":"Updated"}}}
+

# 限制

不能在 admin、local、config 这几个特殊的数据库中指定校验规则。

不能在 system.* collection 中指定校验。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#文档数据库#MongoDB#建模
上次更新: 2023/06/29, 22:27:04
MongoDB 事务
MongoDB 建模示例

+ ← + MongoDB 建模示例→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/5da42d/index.html b/pages/5da42d/index.html new file mode 100644 index 00000000..91ff9a6e --- /dev/null +++ b/pages/5da42d/index.html @@ -0,0 +1,521 @@ + + + + + + Mysql 配置 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-02-29
目录

Mysql 配置

# Mysql 配置

版本：mysql

# 基本配置

[mysqld]
+# GENERAL
+# -------------------------------------------------------------------------------
+datadir = /var/lib/mysql
+socket  = /var/lib/mysql/mysql.sock
+pid_file = /var/lib/mysql/mysql.pid
+user = mysql
+port = 3306
+default_storage_engine = InnoDB
+default_time_zone = '+8：00'
+character_set_server = utf8mb4
+collation_server = utf8mb4_0900_ai_ci
+
+# LOG
+# -------------------------------------------------------------------------------
+log_error = /var/log/mysql/mysql-error.log
+slow_query_log = 1
+slow_query_log_file = /var/log/mysql/mysql-slow.log
+
+# InnoDB
+# -------------------------------------------------------------------------------
+innodb_buffer_pool_size = <value>
+innodb_log_file_size = <value>
+innodb_file_per_table = 1
+innodb_flush_method = O_DIRECT
+
+# MyIsam
+# -------------------------------------------------------------------------------
+key_buffer_size = <value>
+
+# OTHER
+# -------------------------------------------------------------------------------
+tmp_table_size = 32M
+max_heap_table_size = 32M
+max_connections = <value>
+open_files_limit = 65535
+
+[client]
+socket  = /var/lib/mysql/mysql.sock
+port = 3306
+

# 配置项说明

[client]
+# 服务端口号，默认 3306
+port = 3306
+
+# socket 文件
+socket = /var/lib/mysql/mysql.sock
+
+
+
+[mysqld]
+
+# GENERAL
+# -------------------------------------------------------------------------------
+
+# socket 文件
+socket = /var/lib/mysql/mysql.sock
+
+# PID 文件
+pid_file = /var/lib/mysql/mysql.pid
+
+# 启动 mysql 服务进程的用户
+user = mysql
+
+# 服务端口号，默认 3306
+port = 3306
+
+# 默认时区
+default_time_zone = '+8：00'
+
+# Mysql 服务 ID，单点服务时没必要设置
+server-id = 1
+
+# 事务隔离级别，默认为可重复读（REPEATABLE-READ）。（此级别下可能参数很多间隙锁，影响性能，但是修改又影响主从复制及灾难恢复，建议还是修改代码逻辑吧）
+# 隔离级别可选项目：READ-UNCOMMITTED READ-COMMITTED REPEATABLE-READ SERIALIZABLE
+transaction_isolation = REPEATABLE-READ
+
+# 目录配置
+# -------------------------------------------------------------------------------
+
+# mysql 安装根目录
+basedir = /usr/local/mysql-5.7.21
+
+# mysql 数据文件所在目录
+datadir = /var/lib/mysql
+
+# 临时目录 比如 load data infile 会用到，一般都是使用/tmp
+tmpdir = /tmp
+
+# 数据库引擎配置
+# -------------------------------------------------------------------------------
+
+# mysql 5.1 之后，默认引擎是 InnoDB
+default_storage_engine = InnoDB
+
+# 内存临时表默认引擎，默认 InnoDB
+default_tmp_storage_engine = InnoDB
+
+# mysql 5.7 新增特性，磁盘临时表默认引擎，默认 InnoDB
+internal_tmp_disk_storage_engine = InnoDB
+
+# 字符集配置
+# -------------------------------------------------------------------------------
+
+# 数据库默认字符集，主流字符集支持一些特殊表情符号（特殊表情符占用 4 个字节）
+character_set_server = utf8mb4
+
+# 数据库字符集对应一些排序等规则，注意要和 character_set_server 对应
+collation-server = utf8mb4_0900_ai_ci
+
+# 设置 client 连接 mysql 时的字符集，防止乱码
+# init_connect='SET NAMES utf8'
+
+# 是否对 sql 语句大小写敏感，默认值为 0，1 表示不敏感
+lower_case_table_names = 1
+
+# 数据库连接配置
+# -------------------------------------------------------------------------------
+
+# 最大连接数，可设最大值 16384，一般考虑根据同时在线人数设置一个比较综合的数字，鉴于该数值增大并不太消耗系统资源，建议直接设 10000
+# 如果在访问时经常出现 Too Many Connections 的错误提示，则需要增大该参数值
+max_connections = 10000
+
+# 默认值 100，最大错误连接数，如果有超出该参数值个数的中断错误连接，则该主机将被禁止连接。如需对该主机进行解禁，执行：FLUSH HOST
+# 考虑高并发场景下的容错，建议加大。
+max_connect_errors = 10000
+
+# MySQL 打开的文件描述符限制，默认最小 1024;
+# 当 open_files_limit 没有被配置的时候，比较 max_connections\*5 和 ulimit -n 的值，哪个大用哪个，
+# 当 open_file_limit 被配置的时候，比较 open_files_limit 和 max_connections\*5 的值，哪个大用哪个。
+# 注意：仍然可能出现报错信息 Can't create a new thread；此时观察系统 cat /proc/mysql 进程号/limits，观察进程 ulimit 限制情况
+# 过小的话，考虑修改系统配置表，/etc/security/limits.conf 和 /etc/security/limits.d/90-nproc.conf
+open_files_limit = 65535
+
+# 超时配置
+# -------------------------------------------------------------------------------
+
+# MySQL 默认的 wait_timeout 值为 8 个小时，interactive_timeout 参数需要同时配置才能生效
+# MySQL 连接闲置超过一定时间后(单位：秒，此处为 1800 秒)将会被强行关闭
+interactive_timeout = 1800
+wait_timeout = 1800
+
+# 在 MySQL 暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中
+# 官方建议 back_log = 50 + (max_connections / 5)，封顶数为 900
+back_log = 900
+
+# 数据库数据交换配置
+# -------------------------------------------------------------------------------
+# 该参数限制服务器端，接受的数据包大小，如果有 BLOB 子段，建议增大此值，避免写入或者更新出错。有 BLOB 子段，建议改为 1024M
+max_allowed_packet = 128M
+
+# 内存、cache 与 buffer 设置
+
+# 内存临时表的最大值，默认 16M，此处设置成 64M
+tmp_table_size = 64M
+
+# 用户创建的内存表的大小，默认 16M，往往和 tmp_table_size 一起设置，限制用户临时表大小。
+# 超限的话，MySQL 就会自动地把它转化为基于磁盘的 MyISAM 表，存储在指定的 tmpdir 目录下，增大 IO 压力，建议内存大，增大该数值。
+max_heap_table_size = 64M
+
+# 表示这个 mysql 版本是否支持查询缓存。ps：SHOW STATUS LIKE 'qcache%'，与缓存相关的状态变量。
+# have_query_cache
+
+# 这个系统变量控制着查询缓存功能的开启和关闭，0 表示关闭，1 表示打开，2 表示只要 select 中明确指定 SQL_CACHE 才缓存。
+# 看业务场景决定是否使用缓存，不使用，下面就不用配置了。
+# Mysql8 不支持
+query_cache_type = 0
+
+# 默认值 1M，优点是查询缓存可以极大的提高服务器速度，如果你有大量的相同的查询并且很少修改表。
+# 缺点：在你表经常变化的情况下或者如果你的查询原文每次都不同，查询缓存也许引起性能下降而不是性能提升。
+# Mysql8 不支持
+query_cache_size = 64M
+
+# 只有小于此设定值的结果才会被缓冲，保护查询缓冲，防止一个极大的结果集将其他所有的查询结果都覆盖。
+query_cache_limit = 2M
+
+# 每个被缓存的结果集要占用的最小内存，默认值 4kb，一般不怎么调整。
+# 如果 Qcache_free_blocks 值过大，可能是 query_cache_min_res_unit 值过大，应该调小些
+# query_cache_min_res_unit 的估计值：(query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache
+query_cache_min_res_unit = 4kb
+
+# 在一个事务中 binlog 为了记录 SQL 状态所持有的 cache 大小
+# 如果你经常使用大的、多声明的事务，你可以增加此值来获取更大的性能。
+# 所有从事务来的状态都将被缓冲在 binlog 缓冲中然后在提交后一次性写入到 binlog 中
+# 如果事务比此值大，会使用磁盘上的临时文件来替代。
+# 此缓冲在每个连接的事务第一次更新状态时被创建
+binlog_cache_size = 1M
+
+# 日志配置
+# -------------------------------------------------------------------------------
+
+# 日志文件相关设置，一般只开启三种日志，错误日志，慢查询日志，二进制日志。普通查询日志不开启。
+# 普通查询日志，默认值 off，不开启
+general_log = 0
+
+# 普通查询日志存放地址
+general_log_file = /usr/local/mysql-5.7.21/log/mysql-general.log
+
+# 全局动态变量，默认 3，范围：1 ～ 3
+# 表示错误日志记录的信息，1：只记录 error 信息；2：记录 error 和 warnings 信息；3：记录 error、warnings 和普通的 notes 信息。
+log_error_verbosity = 2
+
+# 错误日志文件地址
+log_error = /usr/local/mysql-5.7.21/log/mysql-error.log
+
+# 开启慢查询
+slow_query_log = 1
+
+# 开启慢查询时间，此处为 1 秒，达到此值才记录数据
+long_query_time = 3
+
+# 检索行数达到此数值，才记录慢查询日志中
+min_examined_row_limit = 100
+
+# mysql 5.6.5 新增，用来表示每分钟允许记录到 slow log 的且未使用索引的 SQL 语句次数，默认值为 0，不限制。
+log_throttle_queries_not_using_indexes = 0
+
+# 慢查询日志文件地址
+slow_query_log_file = /var/log/mysql/mysql-slow.log
+
+# 开启记录没有使用索引查询语句
+log-queries-not-using-indexes = 1
+
+# 开启二进制日志
+log_bin = /usr/local/mysql-5.7.21/log/mysql-bin.log
+
+# mysql 清除过期日志的时间，默认值 0，不自动清理，而是使用滚动循环的方式。
+expire_logs_days = 0
+
+# 如果二进制日志写入的内容超出给定值，日志就会发生滚动。你不能将该变量设置为大于 1GB 或小于 4096 字节。 默认值是 1GB。
+max_binlog_size = 1000M
+
+# binlog 的格式也有三种：STATEMENT，ROW，MIXED。mysql 5.7.7 后，默认值从 MIXED 改为 ROW
+# 关于 binlog 日志格式问题，请查阅网络资料
+binlog_format = row
+
+# 表示每 N 次写入 binlog 后，持久化到磁盘，默认值 N=1
+# 建议设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。
+# sync_binlog = 1
+
+# MyISAM 引擎配置
+# -------------------------------------------------------------------------------
+
+# 指定索引缓冲区的大小，为 MYISAM 数据表开启供线程共享的索引缓存，对 INNODB 引擎无效。相当影响 MyISAM 的性能。
+# 不要将其设置大于你可用内存的 30%，因为一部分内存同样被 OS 用来缓冲行数据
+# 甚至在你并不使用 MyISAM 表的情况下，你也需要仍旧设置起 8-64M 内存由于它同样会被内部临时磁盘表使用。
+# 默认值 8M，建议值：对于内存在 4GB 左右的服务器该参数可设置为 256M 或 384M。注意：该参数值设置的过大反而会是服务器整体效率降低！
+key_buffer_size = 64M
+
+# 为每个扫描 MyISAM 的线程分配参数设置的内存大小缓冲区。
+# 默认值 128kb，建议值：16G 内存建议 1M，4G：128kb 或者 256kb 吧
+# 注意，该缓冲区是每个连接独占的，所以总缓冲区大小为 128kb*连接数；极端情况 128kb*maxconnectiosns，会超级大，所以要考虑日常平均连接数。
+# 一般不需要太关心该数值，稍微增大就可以了，
+read_buffer_size = 262144
+
+# 支持任何存储引擎
+# MySQL 的随机读缓冲区大小，适当增大，可以提高性能。
+# 默认值 256kb；建议值：得参考连接数，16G 内存，有人推荐 8M
+# 注意，该缓冲区是每个连接独占的，所以总缓冲区大小为 128kb*连接数；极端情况 128kb*maxconnectiosns，会超级大，所以要考虑日常平均连接数。
+read_rnd_buffer_size = 1M
+
+# order by 或 group by 时用到
+# 支持所有引擎，innodb 和 myisam 有自己的 innodb_sort_buffer_size 和 myisam_sort_buffer_size 设置
+# 默认值 256kb；建议值：得参考连接数，16G 内存，有人推荐 8M。
+# 注意，该缓冲区是每个连接独占的，所以总缓冲区大小为 1M*连接数；极端情况 1M*maxconnectiosns，会超级大。所以要考虑日常平均连接数。
+sort_buffer_size = 1M
+
+# 此缓冲被使用来优化全联合(full JOINs 不带索引的联合)
+# 类似的联合在极大多数情况下有非常糟糕的性能表现，但是将此值设大能够减轻性能影响。
+# 通过 “Select_full_join” 状态变量查看全联合的数量
+# 注意，该缓冲区是每个连接独占的，所以总缓冲区大小为 1M*连接数；极端情况 1M*maxconnectiosns，会超级大。所以要考虑日常平均连接数。
+# 默认值 256kb;建议值：16G 内存，设置 8M。
+join_buffer_size = 1M
+
+# 缓存 linux 文件描述符信息，加快数据文件打开速度
+# 它影响 myisam 表的打开关闭，但是不影响 innodb 表的打开关闭。
+# 默认值 2000，建议值：根据状态变量 Opened_tables 去设定
+table_open_cache = 2000
+
+# 缓存表定义的相关信息，加快读取表信息速度
+# 默认值 1400，最大值 2000，建议值：基本不改。
+table_definition_cache = 1400
+
+# 该参数是 myssql 5.6 后引入的，目的是提高并发。
+# 默认值 1，建议值：cpu 核数，并且<=16
+table_open_cache_instances = 2
+
+# 当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁。可重用，减小了系统开销。
+# 默认值为 9，建议值：两种取值方式，方式一，根据物理内存，1G —> 8；2G —> 16； 3G —> 32； >3G —> 64；
+# 方式二，根据 show status like 'threads%'，查看 Threads_connected 值。
+thread_cache_size = 16
+
+# 默认值 256k，建议值：16/32G 内存，512kb，其他一般不改变，如果报错：Thread stack overrun，就增大看看，
+# 注意，每个线程分配内存空间，所以总内存空间。。。你懂得。
+thread_stack = 512k
+
+# InnoDB 引擎配置
+# -------------------------------------------------------------------------------
+
+# 说明：该参数可以提升扩展性和刷脏页性能。
+# 默认值 1，建议值：4-8；并且必须小于 innodb_buffer_pool_instances
+innodb_page_cleaners = 4
+
+# 说明：一般 8k 和 16k 中选择，8k 的话，cpu 消耗小些，selcet 效率高一点，一般不用改
+# 默认值：16k；建议值：不改，
+innodb_page_size = 16384
+
+# 说明：InnoDB 使用一个缓冲池来保存索引和原始数据，不像 MyISAM。这里你设置越大，你在存取表里面数据时所需要的磁盘 I/O 越少。
+# 在一个独立使用的数据库服务器上，你可以设置这个变量到服务器物理内存大小的 60%-80%
+# 注意别设置的过大，会导致 system 的 swap 空间被占用，导致操作系统变慢，从而减低 sql 查询的效率
+# 默认值：128M，建议值：物理内存的 60%-80%
+innodb_buffer_pool_size = 512M
+
+# 说明：只有当设置 innodb_buffer_pool_size 值大于 1G 时才有意义，小于 1G，instances 默认为 1，大于 1G，instances 默认为 8
+# 但是网络上有评价，最佳性能，每个实例至少 1G 大小。
+# 默认值：1 或 8，建议值：innodb_buffer_pool_size/innodb_buffer_pool_instances >= 1G
+innodb_buffer_pool_instances = 1
+
+# 说明：mysql 5.7 新特性，defines the chunk size for online InnoDB buffer pool resizing operations。
+# 实际缓冲区大小必须为 innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances*倍数，取略大于 innodb_buffer_pool_size
+# 默认值 128M，建议值：默认值就好，乱改反而容易出问题，它会影响实际 buffer pool 大小。
+innodb_buffer_pool_chunk_size = 128M
+
+# 在启动时把热数据加载到内存。默认值为 on，不修改
+innodb_buffer_pool_load_at_startup = 1
+
+# 在关闭时把热数据 dump 到本地磁盘。默认值为 on，不修改
+innodb_buffer_pool_dump_at_shutdown = 1
+
+# 说明：影响 Innodb 缓冲区的刷新算法，建议从小到大配置，直到 zero free pages；innodb_lru_scan_depth \* innodb_buffer_pool_instances defines the amount of work performed by the page cleaner thread each second。
+# 默认值 1024，建议值： 未知
+innodb_lru_scan_depth = 1024
+
+# 说明：事务等待获取资源等待的最长时间，单位为秒，看具体业务情况，一般默认值就好
+# 默认值：50，建议值：看业务。
+innodb_lock_wait_timeout = 60
+
+# 说明：设置了 Mysql 后台任务（例如页刷新和 merge dadta from buffer pool）每秒 io 操作的上限。
+# 默认值：200，建议值：方法一，单盘 sata 设 100，sas10，raid10 设 200，ssd 设 2000，fushion-io 设 50000；方法二，通过测试工具获得磁盘 io 性能后，设置 IOPS 数值/2。
+innodb_io_capacity = 2000
+
+# 说明：该参数是所有缓冲区线程 io 操作的总上限。
+# 默认值：innodb_io_capacity 的两倍。建议值：例如用 iometer 测试后的 iops 数值就好
+innodb_io_capacity_max = 4000
+
+# 说明：控制着 innodb 数据文件及 redo log 的打开、刷写模式，三种模式：fdatasync(默认)，O_DSYNC，O_DIRECT
+# fdatasync：数据文件，buffer pool->os buffer->磁盘；日志文件，buffer pool->os buffer->磁盘；
+# O_DSYNC： 数据文件，buffer pool->os buffer->磁盘；日志文件，buffer pool->磁盘；
+# O_DIRECT： 数据文件，buffer pool->磁盘； 日志文件，buffer pool->os buffer->磁盘；
+# 默认值为空，建议值：使用 SAN 或者 raid，建议用 O_DIRECT，不懂测试的话，默认生产上使用 O_DIRECT
+innodb_flush_method = O_DIRECT
+
+# 说明：mysql5.7 之后默认开启，意思是，每张表一个独立表空间。
+# 默认值 1，开启
+innodb_file_per_table = 1
+
+# 说明：The path where InnoDB creates undo tablespaces。通常等于 undo log 文件的存放目录。
+# 默认值 ./;自行设置
+innodb_undo_directory = /usr/local/mysql-5.7.21/log
+
+# 说明：The number of undo tablespaces used by InnoDB 等于 undo log 文件数量。5.7.21 后开始弃用
+# 默认值为 0，建议默认值就好，不用调整了。
+innodb_undo_tablespaces = 0
+
+# 说明：定义 undo 使用的回滚段数量。5.7.19 后弃用
+# 默认值 128，建议不动，以后弃用了。
+innodb_undo_logs = 128
+
+# 说明：5.7.5 后开始使用，在线收缩 undo log 使用的空间。
+# 默认值：关闭，建议值：开启
+innodb_undo_log_truncate = 1
+
+# 说明：结合 innodb_undo_log_truncate，实现 undo 空间收缩功能
+# 默认值：1G，建议值，不改。
+innodb_max_undo_log_size = 1G
+
+# 说明：重作日志文件的存放目录
+innodb_log_group_home_dir = /usr/local/mysql-5.7.21/log
+
+# 说明：日志文件的大小
+# 默认值：48M，建议值：根据你系统的磁盘空间和日志增长情况调整大小
+innodb_log_file_size = 128M
+
+# 说明：日志组中的文件数量，mysql 以循环方式写入日志
+# 默认值 2，建议值：根据你系统的磁盘空间和日志增长情况调整大小
+innodb_log_files_in_group = 3
+
+# 此参数确定些日志文件所用的内存大小，以 M 为单位。缓冲区更大能提高性能，但意外的故障将会丢失数据。MySQL 开发人员建议设置为 1－8M 之间
+innodb_log_buffer_size = 16M
+
+# 说明：可以控制 log 从系统 buffer 刷入磁盘文件的刷新频率，增大可减轻系统负荷
+# 默认值是 1；建议值不改。系统性能一般够用。
+innodb_flush_log_at_timeout = 1
+
+# 说明：参数可设为 0，1，2；
+# 参数 0：表示每秒将 log buffer 内容刷新到系统 buffer 中，再调用系统 flush 操作写入磁盘文件。
+# 参数 1：表示每次事务提交，redo log 都直接持久化到磁盘。
+# 参数 2：表示每次事务提交，隔 1 秒后再将 redo log 持久化到磁盘。
+# 建议设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
+innodb_flush_log_at_trx_commit = 1
+
+# 说明：限制 Innodb 能打开的表的数据，如果库里的表特别多的情况，请增加这个。
+# 值默认是 2000，建议值：参考数据库表总数再进行调整，一般够用不用调整。
+innodb_open_files = 8192
+
+# innodb 处理 io 读写的后台并发线程数量，根据 cpu 核来确认，取值范围：1-64
+# 默认值：4，建议值：与逻辑 cpu 数量的一半保持一致。
+innodb_read_io_threads = 4
+innodb_write_io_threads = 4
+
+# 默认设置为 0，表示不限制并发数，这里推荐设置为 0，更好去发挥 CPU 多核处理能力，提高并发量
+innodb_thread_concurrency = 0
+
+# 默认值为 4，建议不变。InnoDB 中的清除操作是一类定期回收无用数据的操作。mysql 5.5 之后，支持多线程清除操作。
+innodb_purge_threads = 4
+
+# 说明：mysql 缓冲区分为 new blocks 和 old blocks；此参数表示 old blocks 占比；
+# 默认值：37，建议值，一般不动
+innodb_old_blocks_pct = 37
+
+# 说明：新数据被载入缓冲池，进入 old pages 链区，当 1 秒后再次访问，则提升进入 new pages 链区。
+# 默认值：1000
+innodb_old_blocks_time=1000
+
+# 说明：开启异步 io，可以提高并发性，默认开启。
+# 默认值为 1，建议不动
+innodb_use_native_aio = 1
+
+# 说明：默认为空，使用 data 目录，一般不改。
+innodb_data_home_dir=/usr/local/mysql-5.7.21/data
+
+# 说明：Defines the name，size，and attributes of InnoDB system tablespace data files。
+# 默认值，不指定，默认为 ibdata1：12M：autoextend
+innodb_data_file_path = ibdata1：12M：autoextend
+
+# 说明：设置了 InnoDB 存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小，除非你的数据对象及其多，否则一般默认不改。
+# innodb_additional_mem_pool_size = 16M
+# 说明：The crash recovery mode。只有紧急情况需要恢复数据的时候，才改为大于 1-6 之间数值，含义查下官网。
+# 默认值为 0；
+#innodb_force_recovery = 0
+
+
+
+[mysqldump]
+
+# quick 选项强制 mysqldump 从服务器查询取得记录直接输出而不是取得所有记录后将它们缓存到内存中
+quick
+
+max_allowed_packet = 16M
+
+
+
+[mysql]
+
+# mysql 命令行工具不使用自动补全功能，建议还是改为
+# no-auto-rehash
+auto-rehash
+
+# socket 文件
+socket = /var/lib/mysql/mysql.sock
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#Mysql#配置
上次更新: 2023/06/29, 22:27:04
Mysql 运维
Mysql 常见问题

+ ← + Mysql 常见问题→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/5e3c30/index.html b/pages/5e3c30/index.html new file mode 100644 index 00000000..3b0b55d2 --- /dev/null +++ b/pages/5e3c30/index.html @@ -0,0 +1,138 @@ + + + + + + MongoDB 运维 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-09
目录

MongoDB 运维

# MongoDB 运维

# MongoDB 安装

# Windows

（1）下载并解压到本地

进入官网下载地址：官方下载地址 (opens new window) ，选择合适的版本下载。

（2）创建数据目录

MongoDB 将数据目录存储在 db 目录下。但是这个数据目录不会主动创建，我们在安装完成后需要创建它。

例如：D:\Tools\Server\mongodb\mongodb-4.4.0\data\db

（3）运行 MongoDB 服务

mongod --dbpath D:\Tools\Server\mongodb\mongodb-4.4.0\data\db
+

（4）客户端连接 MongoDB

可以在命令窗口中运行 mongo.exe 命令即可连接上 MongoDB

（5）配置 MongoDB 服务

# Linux

（1）使用安装包安装

安装前我们需要安装各个 Linux 平台依赖包。

Red Hat/CentOS：

sudo yum install libcurl openssl
+

Ubuntu 18.04 LTS ("Bionic")/Debian 10 "Buster"：

sudo apt-get install libcurl4 openssl
+

Ubuntu 16.04 LTS ("Xenial")/Debian 9 "Stretch"：

sudo apt-get install libcurl3 openssl
+

（2）创建数据目录

默认情况下 MongoDB 启动后会初始化以下两个目录：

  • 数据存储目录：/var/lib/mongodb
  • 日志文件目录：/var/log/mongodb

我们在启动前可以先创建这两个目录并设置当前用户有读写权限：

sudo mkdir -p /var/lib/mongo
+sudo mkdir -p /var/log/mongodb
+sudo chown `whoami` /var/lib/mongo     # 设置权限
+sudo chown `whoami` /var/log/mongodb   # 设置权限
+

（3）运行 MongoDB 服务

mongod --dbpath /var/lib/mongo --logpath /var/log/mongodb/mongod.log --fork
+

打开 /var/log/mongodb/mongod.log 文件看到以下信息，说明启动成功。

# tail -10f /var/log/mongodb/mongod.log
+2020-07-09T12:20:17.391+0800 I  NETWORK  [listener] Listening on /tmp/mongodb-27017.sock
+2020-07-09T12:20:17.392+0800 I  NETWORK  [listener] Listening on 127.0.0.1
+2020-07-09T12:20:17.392+0800 I  NETWORK  [listener] waiting for connections on port 27017
+

（4）客户端连接 MongoDB

cd /usr/local/mongodb4/bin
+./mongo
+

Linux 安装脚本 (opens new window)

# 设置用户名、密码

> use admin
+switched to db admin
+> db.createUser({"user":"root","pwd":"root","roles":[{"role":"userAdminAnyDatabase","db":"admin"}]})
+Successfully added user: {
+        "user" : "root",
+        "roles" : [
+                {
+                        "role" : "userAdminAnyDatabase",
+                        "db" : "admin"
+                }
+        ]
+}
+>
+

# 备份和恢复

# 数据备份

在 Mongodb 中，使用 mongodump 命令来备份 MongoDB 数据。该命令可以导出所有数据到指定目录中。

mongodump 命令可以通过参数指定导出的数据量级转存的服务器。

mongodump 命令语法如下：

mongodump -h dbhost -d dbname -o dbdirectory
+

  • -h：MongDB 所在服务器地址，例如：127.0.0.1，当然也可以指定端口号：127.0.0.1:27017

  • -d：需要备份的数据库实例，例如：test

  • -o：备份的数据存放位置，例如：c:\data\dump，当然该目录需要提前建立，在备份完成后，系统自动在 dump 目录下建立一个 test 目录，这个目录里面存放该数据库实例的备份数据。

mongodump 命令可选参数列表如下所示：

语法 描述 实例
mongodump --host HOST_NAME --port PORT_NUMBER 该命令将备份所有 MongoDB 数据 mongodump --host runoob.com --port 27017
mongodump --dbpath DB_PATH --out BACKUP_DIRECTORY mongodump --dbpath /data/db/ --out /data/backup/
mongodump --collection COLLECTION --db DB_NAME 该命令将备份指定数据库的集合。 mongodump --collection mycol --db test

【示例】备份全量数据

$ mongodump -h 127.0.0.1 --port 27017 -o test2
+...
+2020-09-11T11:55:58.086+0800    done dumping test.company (18801 documents)
+2020-09-11T11:56:00.725+0800    [#############...........]  test.people  559101/1000000  (55.9%)
+2020-09-11T11:56:03.725+0800    [###################.....]  test.people  829496/1000000  (82.9%)
+2020-09-11T11:56:06.725+0800    [#####################...]  test.people  884614/1000000  (88.5%)
+2020-09-11T11:56:08.088+0800    [########################]  test.people  1000000/1000000  (100.0%)
+2020-09-11T11:56:08.350+0800    done dumping test.people (1000000 documents)
+

【示例】备份指定数据库

mongodump -h 127.0.0.1 --port 27017 -d admin -o test3
+

# 数据恢复

mongodb 使用 mongorestore 命令来恢复备份的数据。

mongorestore 命令语法如下：

> mongorestore -h <hostname><:port> -d dbname <path>
+

  • --host <:port>, -h <:port>：MongoDB 所在服务器地址，默认为： localhost:27017

  • --db , -d ：需要恢复的数据库实例，例如：test，当然这个名称也可以和备份时候的不一样，比如 test2

  • --drop：恢复的时候，先删除当前数据，然后恢复备份的数据。就是说，恢复后，备份后添加修改的数据都会被删除，慎用哦！

  • <path>：mongorestore 最后的一个参数，设置备份数据所在位置，例如：c:\data\dump\test。你不能同时指定 <path> 和 --dir 选项，--dir 也可以设置备份目录。

  • --dir：指定备份的目录。你不能同时指定 <path> 和 --dir 选项。

【示例】

$ mongorestore -h 127.0.0.1 --port 27017 -d test --dir test --drop
+...
+2020-09-11T11:46:16.053+0800    finished restoring test.tweets (966 documents, 0 failures)
+2020-09-11T11:46:18.256+0800    [###.....................]  test.people  164MB/1.03GB  (15.6%)
+2020-09-11T11:46:21.255+0800    [########................]  test.people  364MB/1.03GB  (34.6%)
+2020-09-11T11:46:24.256+0800    [############............]  test.people  558MB/1.03GB  (53.0%)
+2020-09-11T11:46:27.255+0800    [###############.........]  test.people  700MB/1.03GB  (66.5%)
+2020-09-11T11:46:30.257+0800    [###################.....]  test.people  846MB/1.03GB  (80.3%)
+2020-09-11T11:46:33.255+0800    [######################..]  test.people  990MB/1.03GB  (94.0%)
+2020-09-11T11:46:34.542+0800    [########################]  test.people  1.03GB/1.03GB  (100.0%)
+2020-09-11T11:46:34.543+0800    no indexes to restore
+2020-09-11T11:46:34.543+0800    finished restoring test.people (1000000 documents, 0 failures)
+2020-09-11T11:46:34.544+0800    1000966 document(s) restored successfully. 0 document(s) failed to restore.
+

# 导入导出

mongoimport 和 mongoexport 并不能可靠地保存所有的富文本 BSON 数据类型，因为 JSON 仅能代表一种 BSON 支持的子集类型。因此，数据用这些工具导出导入或许会丢失一些精确程度。

# 导入操作

在 MongoDB 中，使用 mongoimport 来导入数据。 默认情况下，mongoimport 会将数据导入到本地主机端口 27017 上的 MongoDB 实例中。要将数据导入在其他主机或端口上运行的 MongoDB 实例中，请通过包含 --host 和 --port 选项来指定主机名或端口。 使用 --drop 选项删除集合（如果已经存在）。 这样可以确保该集合仅包含您要导入的数据。

语法格式：

mongoimport -h IP --port 端口 -u 用户名 -p 密码 -d 数据库 -c 表名 --type 类型 --headerline --upsert --drop 文件名
+

【示例】导入表数据

$ mongoimport -h 127.0.0.1 --port 27017 -d test -c book --drop test/book.dat
+2020-09-11T10:53:56.359+0800    connected to: mongodb://127.0.0.1:27017/
+2020-09-11T10:53:56.372+0800    dropping: test.book
+2020-09-11T10:53:56.628+0800    431 document(s) imported successfully. 0 document(s) failed to import.
+

【示例】从 json 文件中导入表数据

$ mongoimport -h 127.0.0.1 --port 27017 -d test -c student --upsert test/student.json
+2020-09-11T11:02:55.907+0800    connected to: mongodb://127.0.0.1:27017/
+2020-09-11T11:02:56.068+0800    200 document(s) imported successfully. 0 document(s) failed to import.
+

【示例】从 csv 文件中导入表数据

$ mongoimport -h 127.0.0.1 --port 27017 -d test -c product --type csv --headerline test/product.csv
+2020-09-11T11:07:49.788+0800    connected to: mongodb://127.0.0.1:27017/
+2020-09-11T11:07:51.051+0800    11 document(s) imported successfully. 0 document(s) failed to import.
+

【示例】导入部分表字段数据

$ mongoimport -h 127.0.0.1 --port 27017 -d test -c product --type json --upsertFields name,price test/product.json
+2020-09-11T11:14:05.410+0800    connected to: mongodb://127.0.0.1:27017/
+2020-09-11T11:14:05.612+0800    11 document(s) imported successfully. 0 document(s) failed to import.
+

# 导出操作

语法格式：

mongoexport -h <IP> --port <端口> -u <用户名> -p <密码> -d <数据库> -c <表名> -f <字段> -q <条件导出> --csv -o <文件名>
+
  • -f：导出指字段，以逗号分割，-f name,email,age 导出 name,email,age 这三个字段
  • -q：可以根查询条件导出，-q '{ "uid" : "100" }' 导出 uid 为 100 的数据
  • --csv：表示导出的文件格式为 csv 的，这个比较有用，因为大部分的关系型数据库都是支持 csv，在这里有共同点

【示例】导出整张表

$ mongoexport -h 127.0.0.1 --port 27017 -d test -c product -o test/product.dat
+2020-09-11T10:44:23.161+0800    connected to: mongodb://127.0.0.1:27017/
+2020-09-11T10:44:23.177+0800    exported 11 records
+

【示例】导出表到 json 文件

$ mongoexport -h 127.0.0.1 --port 27017 -d test -c product --type json -o test/product.json
+2020-09-11T10:49:52.735+0800    connected to: mongodb://127.0.0.1:27017/
+2020-09-11T10:49:52.750+0800    exported 11 records
+

【示例】导出表中部分字段到 csv 文件

$ mongoexport -h 127.0.0.1 --port 27017 -d test -c product --type csv -f name,price -o test/product.csv
+2020-09-11T10:47:33.160+0800    connected to: mongodb://127.0.0.1:27017/
+2020-09-11T10:47:33.176+0800    exported 11 records
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#文档数据库#MongoDB#运维
上次更新: 2023/06/29, 22:27:04
MongoDB 分片
Redis 面试总结

+ ← + Redis 面试总结→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/5ed2a2/index.html b/pages/5ed2a2/index.html new file mode 100644 index 00000000..64c596fd --- /dev/null +++ b/pages/5ed2a2/index.html @@ -0,0 +1,62 @@ + + + + + + ShardingSphere 简介 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-10-08
目录

ShardingSphere 简介

# ShardingSphere 简介

# 简介

# ShardingSphere 组件

ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar（计划中）这 3 款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。

img

# ShardingSphere-JDBC

定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

  • 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。
  • 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。
  • 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，Oracle，SQLServer，PostgreSQL 以及任何遵循 SQL92 标准的数据库。

img

# Sharding-Proxy

定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端(如：MySQL Command Client, MySQL Workbench, Navicat 等)操作数据，对 DBA 更加友好。

  • 向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用。
  • 适用于任何兼容 MySQL/PostgreSQL 协议的的客户端。

img

# Sharding-Sidecar（TODO）

定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库的访问。 通过无中心、零侵入的方案提供与数据库交互的的啮合层，即 Database Mesh，又可称数据库网格。

Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互进行有效地梳理。 使用 Database Mesh，访问数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。

img

Sharding-JDBC Sharding-Proxy Sharding-Sidecar
数据库 任意 MySQL MySQL
连接消耗数 高 低 高
异构语言 仅 Java 任意 任意
性能 损耗低 损耗略高 损耗低
无中心化 是 否 是
静态入口 无 有 无

# 混合架构

ShardingSphere-JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；ShardingSphere-Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。

Apache ShardingSphere 是多接入端共同组成的生态圈。 通过混合使用 ShardingSphere-JDBC 和 ShardingSphere-Proxy，并采用同一注册中心统一配置分片策略，能够灵活的搭建适用于各种场景的应用系统，使得架构师更加自由地调整适合与当前业务的最佳系统架构。

img

# 功能列表

# 数据分片

  • 分库 & 分表
  • 读写分离
  • 分片策略定制化
  • 无中心化分布式主键

# 分布式事务

  • 标准化事务接口
  • XA 强一致事务
  • 柔性事务

# 数据库治理

  • 分布式治理
  • 弹性伸缩
  • 可视化链路追踪
  • 数据加密

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#中间件#分库分表
上次更新: 2023/06/29, 22:27:04
数据结构与数据库索引
ShardingSphere Jdbc

+ ← + ShardingSphere Jdbc→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/5f1bc3/index.html b/pages/5f1bc3/index.html new file mode 100644 index 00000000..d2fa31af --- /dev/null +++ b/pages/5f1bc3/index.html @@ -0,0 +1,62 @@ + + + + + + HBase Java API 高级特性之协处理器 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2023-03-16
目录

HBase Java API 高级特性之协处理器

# HBase Java API 高级特性之协处理器

# 简述

在使用 HBase 时，如果你的数据量达到了数十亿行或数百万列，此时能否在查询中返回大量数据将受制于网络的带宽，即便网络状况允许，但是客户端的计算处理也未必能够满足要求。在这种情况下，协处理器（Coprocessors）应运而生。它允许你将业务计算代码放入在 RegionServer 的协处理器中，将处理好的数据再返回给客户端，这可以极大地降低需要传输的数据量，从而获得性能上的提升。同时协处理器也允许用户扩展实现 HBase 目前所不具备的功能，如权限校验、二级索引、完整性约束等。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#大数据#HBase#API
上次更新: 2023/06/29, 22:27:04
HBase Java API 高级特性之过滤器
HBase Java API 其他高级特性

+ ← + HBase Java API 其他高级特性→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/5fe0f3/index.html b/pages/5fe0f3/index.html new file mode 100644 index 00000000..61b97c6e --- /dev/null +++ b/pages/5fe0f3/index.html @@ -0,0 +1,78 @@ + + + + + + Mysql 应用指南 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-07-13
目录

Mysql 应用指南

# Mysql 应用指南

# SQL 执行过程

学习 Mysql，最好是先从宏观上了解 Mysql 工作原理。

参考：Mysql 工作流

# 存储引擎

在文件系统中，Mysql 将每个数据库（也可以成为 schema）保存为数据目录下的一个子目录。创建表示，Mysql 会在数据库子目录下创建一个和表同名的 .frm 文件保存表的定义。因为 Mysql 使用文件系统的目录和文件来保存数据库和表的定义，大小写敏感性和具体平台密切相关。Windows 中大小写不敏感；类 Unix 中大小写敏感。不同的存储引擎保存数据和索引的方式是不同的，但表的定义则是在 Mysql 服务层统一处理的。

# 选择存储引擎

# Mysql 内置的存储引擎

mysql> SHOW ENGINES;
++--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
+| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
++--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
+| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
+| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
+| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
+| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
+| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
+| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
+| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
+| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
+| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
++--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
+9 rows in set (0.00 sec)
+
  • InnoDB - Mysql 的默认事务型存储引擎，并且提供了行级锁和外键的约束。性能不错且支持自动崩溃恢复。
  • MyISAM - Mysql 5.1 版本前的默认存储引擎。特性丰富但不支持事务，也不支持行级锁和外键，也没有崩溃恢复功能。
  • CSV - 可以将 CSV 文件作为 Mysql 的表来处理，但这种表不支持索引。
  • Memory - 适合快速访问数据，且数据不会被修改，重启丢失也没有关系。
  • NDB - 用于 Mysql 集群场景。

# 如何选择合适的存储引擎

大多数情况下，InnoDB 都是正确的选择，除非需要用到 InnoDB 不具备的特性。

如果应用需要选择 InnoDB 以外的存储引擎，可以考虑以下因素：

  • 事务：如果需要支持事务，InnoDB 是首选。如果不需要支持事务，且主要是 SELECT 和 INSERT 操作，MyISAM 是不错的选择。所以，如果 Mysql 部署方式为主备模式，并进行读写分离。那么可以这么做：主节点只支持写操作，默认引擎为 InnoDB；备节点只支持读操作，默认引擎为 MyISAM。
  • 并发：MyISAM 只支持表级锁，而 InnoDB 还支持行级锁。所以，InnoDB 并发性能更高。
  • 外键：InnoDB 支持外键。
  • 备份：InnoDB 支持在线热备份。
  • 崩溃恢复：MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多，而且恢复的速度也更慢。
  • 其它特性：MyISAM 支持压缩表和空间数据索引。

# 转换表的存储引擎

下面的语句可以将 mytable 表的引擎修改为 InnoDB

ALTER TABLE mytable ENGINE = InnoDB
+

# MyISAM

MyISAM 设计简单，数据以紧密格式存储。对于只读数据，或者表比较小、可以容忍修复操作，则依然可以使用 MyISAM。

MyISAM 引擎使用 B+Tree 作为索引结构，叶节点的 data 域存放的是数据记录的地址。

MyISAM 提供了大量的特性，包括：全文索引、压缩表、空间函数等。但是，MyISAM 不支持事务和行级锁。并且 MyISAM 不支持崩溃后的安全恢复。

# InnoDB

InnoDB 是 MySQL 默认的事务型存储引擎，只有在需要 InnoDB 不支持的特性时，才考虑使用其它存储引擎。

然 InnoDB 也使用 B+Tree 作为索引结构，但具体实现方式却与 MyISAM 截然不同。MyISAM 索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。而在 InnoDB 中，表数据文件本身就是按 B+Tree 组织的一个索引结构，这棵树的叶节点 data 域保存了完整的数据记录。这个索引的 key 是数据表的主键，因此InnoDB 表数据文件本身就是主索引。

InnoDB 采用 MVCC 来支持高并发，并且实现了四个标准的隔离级别。其默认级别是可重复读（REPEATABLE READ），并且通过间隙锁（next-key locking）防止幻读。

InnoDB 是基于聚簇索引建立的，与其他存储引擎有很大不同。在索引中保存了数据，从而避免直接读取磁盘，因此对查询性能有很大的提升。

内部做了很多优化，包括从磁盘读取数据时采用的可预测性读、能够加快读操作并且自动创建的自适应哈希索引、能够加速插入操作的插入缓冲区等。

支持真正的在线热备份。其它存储引擎不支持在线热备份，要获取一致性视图需要停止对所有表的写入，而在读写混合场景中，停止写入可能也意味着停止读取。

# 数据类型

# 整型

TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 分别使用 8, 16, 24, 32, 64 位存储空间，一般情况下越小的列越好。

UNSIGNED 表示不允许负值，大致可以使正数的上限提高一倍。

INT(11) 中的数字只是规定了交互工具显示字符的个数，对于存储和计算来说是没有意义的。

# 浮点型

FLOAT 和 DOUBLE 为浮点类型。

DECIMAL 类型主要用于精确计算，代价较高，应该尽量只在对小数进行精确计算时才使用 DECIMAL ——例如存储财务数据。数据量比较大的时候，可以使用 BIGINT 代替 DECIMAL。

FLOAT、DOUBLE 和 DECIMAL 都可以指定列宽，例如 DECIMAL(18, 9) 表示总共 18 位，取 9 位存储小数部分，剩下 9 位存储整数部分。

# 字符串

主要有 CHAR 和 VARCHAR 两种类型，一种是定长的，一种是变长的。

VARCHAR 这种变长类型能够节省空间，因为只需要存储必要的内容。但是在执行 UPDATE 时可能会使行变得比原来长。当超出一个页所能容纳的大小时，就要执行额外的操作。MyISAM 会将行拆成不同的片段存储，而 InnoDB 则需要分裂页来使行放进页内。

VARCHAR 会保留字符串末尾的空格，而 CHAR 会删除。

# 时间和日期

MySQL 提供了两种相似的日期时间类型：DATATIME 和 TIMESTAMP。

# DATATIME

能够保存从 1001 年到 9999 年的日期和时间，精度为秒，使用 8 字节的存储空间。

它与时区无关。

默认情况下，MySQL 以一种可排序的、无歧义的格式显示 DATATIME 值，例如“2008-01-16 22:37:08”，这是 ANSI 标准定义的日期和时间表示方法。

# TIMESTAMP

和 UNIX 时间戳相同，保存从 1970 年 1 月 1 日午夜（格林威治时间）以来的秒数，使用 4 个字节，只能表示从 1970 年 到 2038 年。

它和时区有关，也就是说一个时间戳在不同的时区所代表的具体时间是不同的。

MySQL 提供了 FROM_UNIXTIME() 函数把 UNIX 时间戳转换为日期，并提供了 UNIX_TIMESTAMP() 函数把日期转换为 UNIX 时间戳。

默认情况下，如果插入时没有指定 TIMESTAMP 列的值，会将这个值设置为当前时间。

应该尽量使用 TIMESTAMP，因为它比 DATETIME 空间效率更高。

# BLOB 和 TEXT

BLOB 和 TEXT 都是为了存储大的数据而设计，前者存储二进制数据，后者存储字符串数据。

不能对 BLOB 和 TEXT 类型的全部内容进行排序、索引。

# 枚举类型

大多数情况下没有使用枚举类型的必要，其中一个缺点是：枚举的字符串列表是固定的，添加和删除字符串（枚举选项）必须使用ALTER TABLE（如果只只是在列表末尾追加元素，不需要重建表）。

# 类型的选择

  • 整数类型通常是标识列最好的选择，因为它们很快并且可以使用 AUTO_INCREMENT。

  • ENUM 和 SET 类型通常是一个糟糕的选择，应尽量避免。

  • 应该尽量避免用字符串类型作为标识列，因为它们很消耗空间，并且通常比数字类型慢。对于 MD5、SHA、UUID 这类随机字符串，由于比较随机，所以可能分布在很大的空间内，导致 INSERT 以及一些 SELECT 语句变得很慢。

    • 如果存储 UUID ，应该移除 - 符号；更好的做法是，用 UNHEX() 函数转换 UUID 值为 16 字节的数字，并存储在一个 BINARY(16) 的列中，检索时，可以通过 HEX() 函数来格式化为 16 进制格式。

# 索引

详见：Mysql 索引

# 锁

详见：Mysql 锁

# 事务

详见：Mysql 事务

# 性能优化

详见：Mysql 性能优化

# 复制

# 主从复制

Mysql 支持两种复制：基于行的复制和基于语句的复制。

这两种方式都是在主库上记录二进制日志，然后在从库重放日志的方式来实现异步的数据复制。这意味着：复制过程存在时延，这段时间内，主从数据可能不一致。

主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。

  • binlog 线程 ：负责将主服务器上的数据更改写入二进制文件（binlog）中。
  • I/O 线程 ：负责从主服务器上读取二进制日志文件，并写入从服务器的中继日志中。
  • SQL 线程 ：负责读取中继日志并重放其中的 SQL 语句。

# 读写分离

主服务器用来处理写操作以及实时性要求比较高的读操作，而从服务器用来处理读操作。

读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。

MySQL 读写分离能提高性能的原因在于：

  • 主从服务器负责各自的读和写，极大程度缓解了锁的争用；
  • 从服务器可以配置 MyISAM 引擎，提升查询性能以及节约系统开销；
  • 增加冗余，提高可用性。

# 参考资料

# 传送门

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#Mysql
上次更新: 2023/06/29, 22:27:04
SQL Cheat Sheet
MySQL 工作流

+ ← + MySQL 工作流→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/615afe/index.html b/pages/615afe/index.html new file mode 100644 index 00000000..4560ff1d --- /dev/null +++ b/pages/615afe/index.html @@ -0,0 +1,67 @@ + + + + + + Redis 哨兵 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-24
目录

Redis 哨兵

# Redis 哨兵

Redis 哨兵（Sentinel）是 Redis 的高可用性（Hight Availability）解决方案。

Redis 哨兵是 Raft 算法 (opens new window) 的具体实现。

img

# 一、哨兵简介

Redis 哨兵（Sentinel）是 Redis 的高可用性（Hight Availability）解决方案：由一个或多个 Sentinel 实例组成的 Sentinel 系统可以监视任意多个主服务器，以及这些主服务器的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

img

Sentinel 的主要功能如下：

  • 监控（Monitoring） - Sentinel 不断检查主从服务器是否正常在工作。
  • 通知（Notification） - Sentinel 可以通过一个 api 来通知系统管理员或者另外的应用程序，被监控的 Redis 实例有一些问题。
  • 自动故障转移（Automatic Failover） - 如果一个主服务器下线，Sentinel 会开始自动故障转移：把一个从节点提升为主节点，并重新配置其他的从节点使用新的主节点，使用 Redis 服务的应用程序在连接的时候也被通知新的地址。
  • 配置提供者（Configuration provider） - Sentinel 给客户端的服务发现提供来源：对于一个给定的服务，客户端连接到 Sentinels 来寻找当前主节点的地址。当故障转移发生的时候，Sentinel 将报告新的地址。

# 二、启动哨兵

启动一个 Sentinel 可以使用下面任意一条命令，两条命令效果完全相同。

redis-sentinel /path/to/sentinel.conf
+redis-server /path/to/sentinel.conf --sentinel
+

当一个 Sentinel 启动时，它需要执行以下步骤：

  1. 初始化服务器。
  2. 使用 Sentinel 专用代码。
  3. 初始化 Sentinel 状态。
  4. 初始化 Sentinel 的主服务器列表。
  5. 创建连向被监视的主服务器的网络连接。

Sentinel 本质上是一个运行在特殊状模式下的 Redis 服务器。

Sentinel 模式下 Redis 服务器只支持 PING、SENTINEL、INFO、SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE 七个命令。

创建连向被监视的主服务器的网络连接，Sentinel 将成为主服务器的客户端，它可以向主服务器发送命令，并从命令回复中获取相关的信息。对于每个被 Sentinel 监视的主服务器，Sentinel 会创建两个连向主服务器的异步网络：

  • 命令连接：专门用于向主服务器发送命令，并接受命令回复。
  • 订阅连接：专门用于订阅主服务器的 __sentinel__:hello 频道。

# 三、监控

# 检测服务器状态

Sentinel 向 Redis 服务器发送 PING 命令，检查其状态。

默认情况下，每个 Sentinel 节点会以 每秒一次 的频率对 Redis 节点和 其它 的 Sentinel 节点发送 PING 命令，并通过节点的 回复 来判断节点是否在线。

  • 主观下线：主观下线 适用于所有 主节点 和 从节点。如果在 down-after-milliseconds 毫秒内，Sentinel 没有收到 目标节点 的有效回复，则会判定 该节点 为 主观下线。
  • 客观下线：客观下线 只适用于 主节点。当 Sentinel 将一个主服务器判断为主管下线后，为了确认这个主服务器是否真的下线，会向同样监视这一主服务器的其他 Sentinel 询问，看它们是否也认为主服务器已经下线。当足够数量的 Sentinel 认为主服务器已下线，就判定其为客观下线，并对其执行故障转移操作。 +
    • Sentinel 节点通过 sentinel is-master-down-by-addr 命令，向其它 Sentinel 节点询问对该节点的 状态判断。

# 获取服务器信息

Sentinel 向主服务器发送 INFO 命令，获取主服务器及它的从服务器信息。

  • 获取主服务器信息 - Sentinel 默认会以每十秒一次的频率，通过命令连接向被监视的主服务器发送 INFO 命令，并通过分析 INFO 命令的回复来获取主服务器的当前信息。 +
    • 主服务自身信息：包括 run_id 域记录的服务器运行 ID，以及 role 域记录的服务器角色
    • 主服务的从服务器信息：包括 IP 地址和端口号
  • 获取从服务器信息 - 当 Sentinel 发现主服务器有新的从服务器出现时，Sentinel 除了会为这个新的从服务器创建相应的实例结构之外，Sentinel 还会创建连接到从服务器的命令连接和订阅连接。

# 四、通知

对于每个与 Sentinel 连接的服务器，Sentinel 既会向服务器的 __sentinel__:hello 频道发送消息，也会订阅服务器的 __sentinel__:hello 频道的消息。

img

# 向服务器发送消息

在默认情况下，Sentinel 会以每两秒一次的频率，通过命令向所有被监视的主服务器和从服务器发送以下格式的命令。

PUBLISH __sentinel__:hello "<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>"
+

这条命令向服务器的 __sentinel__:hello 频道发送一条消息。

# 接收服务器的消息

当 Sentinel 与一个主服务器或从服务器建立起订阅连接后，Sentinel 就会通过订阅连接，向服务器发送以下命令：SUBSCRIBE __sentinel__:hello。

Sentinel 对 __sentinel__:hello 频道的订阅会一直持续到 Sentinel 与服务器断开连接为止。

# 五、选举 Leader

Redis Sentinel 系统选举 Leader 的算法是 Raft (opens new window) 的实现。

Raft 是一种共识性算法，想了解其原理，可以参考 深入剖析共识性算法 Raft (opens new window)。

当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个 Sentinel 会进行协商，选举出一个领头的 Sentinel，并由领头 Sentinel 对下线主服务器执行故障转移操作。

所有在线 Sentinel 都有资格被选为 Leader。

每个 Sentinel 节点都需要 定期执行 以下任务：

（1）每个 Sentinel 以 每秒钟 一次的频率，向它所知的 主服务器、从服务器 以及其他 Sentinel 实例 发送一个 PING 命令。

img

（2）如果一个 实例（instance）距离 最后一次 有效回复 PING 命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel 标记为 主观下线。

img

（3）如果一个 主服务器 被标记为 主观下线，那么正在 监视 这个 主服务器 的所有 Sentinel 节点，要以 每秒一次 的频率确认 主服务器 的确进入了 主观下线 状态。

img

（4）如果一个 主服务器 被标记为 主观下线，并且有 足够数量 的 Sentinel（至少要达到 配置文件 指定的数量）在指定的 时间范围 内同意这一判断，那么这个 主服务器 被标记为 客观下线。

img

（5）在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率，向它已知的所有 主服务器 和 从服务器 发送 INFO 命令。当一个 主服务器 被 Sentinel 标记为 客观下线 时，Sentinel 向 下线主服务器 的所有 从服务器 发送 INFO 命令的频率，会从 10 秒一次改为 每秒一次。

img

（6）Sentinel 和其他 Sentinel 协商 主节点 的状态，如果 主节点 处于 SDOWN 状态，则投票自动选出新的 主节点。将剩余的 从节点 指向 新的主节点 进行 数据复制。

img

（7）当没有足够数量的 Sentinel 同意 主服务器 下线时， 主服务器 的 客观下线状态 就会被移除。当 主服务器 重新向 Sentinel 的 PING 命令返回 有效回复 时，主服务器 的 主观下线状态 就会被移除。

img

注意：一个有效的 PING 回复可以是：+PONG、-LOADING 或者 -MASTERDOWN。如果 服务器 返回除以上三种回复之外的其他回复，又或者在 指定时间 内没有回复 PING 命令， 那么 Sentinel 认为服务器返回的回复 无效（non-valid）。

# 六、故障转移

在选举产生出 Sentinel Leader 后，Sentinel Leader 将对已下线的主服务器执行故障转移操作。操作含以下三个步骤：

（一）选出新的主服务器

故障转移第一步，是 Sentinel Leader 在已下线主服务属下的所有从服务器中，挑选一个状态良好、数据完整的从服务器。然后，向这个从服务器发送 SLAVEOF no one 命令，将其转换为主服务器。

Sentinel Leader 如何选出新的主服务器：

  • 删除列表中所有处于下线或断线状态的从服务器。
  • 删除列表中所有最近五秒没有回复过 Sentinel Leader 的 INFO 命令的从服务器。
  • 删除所有与已下线主服务器连接断开超过 down-after-milliseconds * 10 毫秒的从服务器（down-after-milliseconds 指定了判断主服务器下线所需的时间）。
  • 之后， Sentinel Leader 先选出优先级最高的从服务器；如果优先级一样高，再选择复制偏移量最大的从服务器；如果结果还不唯一，则选出运行 ID 最小的从服务器。

（二）修改从服务器的复制目标

选出新的主服务器后，Sentinel Leader 会向所有从服务器发送 SLAVEOF 命令，让它们去复制新的主服务器。

（三）将旧的主服务器变为从服务器

Sentinel Leader 将旧的主服务器标记为从服务器。当旧的主服务器重新上线，Sentinel 会向它发送 SLAVEOF 命令，让其成为从服务器。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#KV数据库#Redis#哨兵
上次更新: 2023/06/29, 22:27:04
Redis 复制
Redis 集群

+ ← + Redis 集群→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/62f8d9/index.html b/pages/62f8d9/index.html new file mode 100644 index 00000000..82d855c0 --- /dev/null +++ b/pages/62f8d9/index.html @@ -0,0 +1,65 @@ + + + + + + HBase 架构 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-07-24
目录

HBase 架构

# HBase 架构

HBase 是一个在 HDFS 上开发的面向列的分布式数据库。

# HBase 存储架构

在 HBase 中，表被分割成多个更小的块然后分散的存储在不同的服务器上，这些小块叫做 Regions，存放 Regions 的地方叫做 RegionServer。Master 进程负责处理不同的 RegionServer 之间的 Region 的分发。

# 概览

img

HBase 主要处理两种文件：预写日志（WAL）和实际数据文件 HFile。一个基本的流程是客户端首先联系 ZooKeeper 集群查找行键。上述过程是通过 ZooKeeper 获取欧含有 -ROOT- 的 region 服务器来完成的。通过含有 -ROOT- 的 region 服务器可以查询到含有 .META. 表中对应的 region 服务器名，其中包含请求的行键信息。这两种内容都会被缓存下来，并且只查询一次。最终，通过查询 .META. 服务器来获取客户端查询的行键数据所在 region 的服务器名。

# Region

HBase Table 中的所有行按照 Row Key 的字典序排列。HBase Table 根据 Row Key 的范围分片，每个分片叫做 Region。一个 Region 包含了在 start key 和 end key 之间的所有行。

img

HBase 支持自动分区：每个表初始只有一个 Region，随着数据不断增加，Region 会不断增大，当增大到一个阀值的时候，Region 就会分裂为两个新的 Region。当 Table 中的行不断增多，就会有越来越多的 Region。

Region 是 HBase 中分布式存储和负载均衡的最小单元。这意味着不同的 Region 可以分布在不同的 Region Server 上。但一个 Region 是不会拆分到多个 Server 上的。

img

# Region Server

Region 只不过是表被拆分，并分布在 Region Server。

Region Server 运行在 HDFS 的 DataNode 上。它具有以下组件：

  • WAL(Write Ahead Log，预写日志)：用于存储尚未进持久化存储的数据记录，以便在发生故障时进行恢复。如果写 WAL 失败了，那么修改数据的完整操作就是失败的。 +
    • 通常情况，每个 RegionServer 只有一个 WAL 实例。在 2.0 之前，WAL 的实现叫做 HLog
    • WAL 位于 /hbase/WALs/ 目录下
    • 如果每个 RegionServer 只有一个 WAL，由于 HDFS 必须是连续的，导致必须写 WAL 连续的，然后出现性能问题。MultiWAL 可以让 RegionServer 同时写多个 WAL 并行的，通过 HDFS 底层的多管道，最终提升总的吞吐量，但是不会提升单个 Region 的吞吐量。
  • BlockCache：读缓存。它将频繁读取的数据存储在内存中，如果存储不足，它将按照 最近最少使用原则 清除多余的数据。
  • MemStore：写缓存。它存储尚未写入磁盘的新数据，并会在数据写入磁盘之前对其进行排序。每个 Region 上的每个列族都有一个 MemStore。
  • HFile：将行数据按照 Key/Values 的形式存储在文件系统上。HFile 是 HBase 在 HDFS 中存储数据的格式，它包含多层的索引，这样在 HBase 检索数据的时候就不用完全的加载整个文件。HFile 存储的根目录默认为为 /hbase。索引的大小(keys 的大小，数据量的大小)影响 block 的大小，在大数据集的情况下，block 的大小设置为每个 RegionServer 1GB 也是常见的。 +
    • 起初，HFile 中并没有任何 Block，数据还存在于 MemStore 中。
    • Flush 发生时，创建 HFile Writer，第一个空的 Data Block 出现，初始化后的 Data Block 中为 Header 部分预留了空间，Header 部分用来存放一个 Data Block 的元数据信息。
    • 而后，位于 MemStore 中的 KeyValues 被一个个 append 到位于内存中的第一个 Data Block 中：

img

Region Server 存取一个子表时，会创建一个 Region 对象，然后对表的每个列族创建一个 Store 实例，每个 Store 会有 0 个或多个 StoreFile 与之对应，每个 StoreFile 则对应一个 HFile，HFile 就是实际存储在 HDFS 上的文件。

# HBase 系统架构

img

和 HDFS、YARN 一样，HBase 也遵循 master / slave 架构：

  • HBase 有一个 master 节点。master 节点负责协调管理 region server 节点。 +
    • master 负责将 region 分配给 region server 节点；
    • master 负责恢复 region server 节点的故障。
  • HBase 有多个 region server 节点。region server 节点负责零个或多个 region 的管理并响应客户端的读写请求。region server 节点还负责 region 的划分并通知 master 节点有了新的子 region。
  • HBase 依赖 ZooKeeper 来实现故障恢复。

# Master Server

Master Server 负责协调 Region Server。具体职责如下：

  • 为 Region Server 分配 Region ；
  • 负责 Region Server 的负载均衡 ；
  • 发现失效的 Region Server 并重新分配其上的 Region；
  • GFS 上的垃圾文件回收；
  • 处理 Schema 的更新请求。

img

# Region Server

  • Region Server 负责维护 Master Server 分配给它的 Region，并处理发送到 Region 上的 IO 请求；
  • 当 Region 过大，Region Server 负责自动分区，并通知 Master Server 记录更新。

img

# ZooKeeper

HBase 依赖 ZooKeeper 作为分布式协调服务来维护集群中的服务器状态。Zookeeper 维护哪些服务器是活动的和可用的，并提供服务器故障通知。集群至少应该有 3 个节点。

ZooKeeper 的作用：

  • 保证任何时候，集群中只有一个 Master；
  • 存储所有 Region 的寻址入口；
  • 实时监控 Region Server 的状态，将 Region Server 的上线和下线信息实时通知给 Master；
  • 存储 HBase 的 Schema，包括有哪些 Table，每个 Table 有哪些 Column Family 等信息。

img

以上，最重要的一点是 ZooKeeper 如何保证 HBase 集群中只有一个 Master Server 的呢？

  • 所有 Master Server 会竞争 Zookeeper 的 znode 锁（一个临时节点），只有一个 Master Server 能够创建成功，此时该 Master 就是主 Master。
  • 主 Master 会定期向 Zookeeper 发送心跳。从 Master 则通过 Watcher 机制对主 Master 所在节点进行监听。
  • 如果，主 Master 未能及时发送心跳，则其持有的 ZooKeeper 会话会过期，相应的 znode 锁（一个临时节点）会被自动删除。这会触发定义在该节点上的 Watcher 事件，所有从 Master 会得到通知，并再次开始竞争 znode 锁，直到完成主 Master 的选举。

HBase 内部保留名为 hbase:meta 的特殊目录表（catalog table）。它维护着当前集群上所有 region 的列表、状态和位置。hbase:meta 表中的项使用 region 作为键。region 名由所属的表名、region 的起始行、region的创建时间以及基于整体计算得出的 MD5 组成。

# HBase 读写流程

# 写入数据的流程

  1. Client 向 Region Server 提交写请求；
  2. Region Server 找到目标 Region；
  3. Region 检查数据是否与 Schema 一致；
  4. 如果客户端没有指定版本，则获取当前系统时间作为数据版本；
  5. 将更新写入 WAL Log；
  6. 将更新写入 Memstore；
  7. 判断 Memstore 存储是否已满，如果存储已满则需要 flush 为 Store Hfile 文件。

更为详细写入流程可以参考：HBase － 数据写入流程解析 (opens new window)

# 读取数据的流程

以下是客户端首次读写 HBase 上数据的流程：

  1. 客户端从 Zookeeper 获取 META 表所在的 Region Server；
  2. 客户端访问 META 表所在的 Region Server，从 META 表中查询到访问行键所在的 Region Server，之后客户端将缓存这些信息以及 META 表的位置；
  3. 客户端从行键所在的 Region Server 上获取数据。

如果再次读取，客户端将从缓存中获取行键所在的 Region Server。这样客户端就不需要再次查询 META 表，除非 Region 移动导致缓存失效，这样的话，则将会重新查询并更新缓存。

注：META 表是 HBase 中一张特殊的表，它保存了所有 Region 的位置信息，META 表自己的位置信息则存储在 ZooKeeper 上。

img

更为详细读取数据流程参考：

HBase 原理－数据读取流程解析 (opens new window)

HBase 原理－迟到的‘数据读取流程部分细节 (opens new window)

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#大数据#HBase
上次更新: 2023/06/29, 22:27:04
HBase Schema 设计
HBase Java API 基础特性

+ ← + HBase Java API 基础特性→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/74675e/index.html b/pages/74675e/index.html new file mode 100644 index 00000000..7c5ede88 --- /dev/null +++ b/pages/74675e/index.html @@ -0,0 +1,60 @@ + + + + + + Elasticsearch 教程 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-04-11
目录

Elasticsearch 教程

# Elasticsearch 教程

Elasticsearch 是一个基于 Lucene 的搜索和数据分析工具，它提供了一个分布式服务。Elasticsearch 是遵从 Apache 开源条款的一款开源产品，是当前主流的企业级搜索引擎。

# 📖 内容

# Elasticsearch 面试总结 💯

# Elasticsearch 快速入门

# Elasticsearch 简介

# Elasticsearch 索引管理

# Elasticsearch 映射

# Elasticsearch 查询

# Elasticsearch 高亮

# Elasticsearch 排序

# Elasticsearch 聚合

# Elasticsearch 分析器

# Elasticsearch 性能优化

# Elasticsearch Rest API

# ElasticSearch Java API 之 High Level REST Client

# Elasticsearch 集群和分片

# Elasticsearch 运维

# 📚 资料

# 🚪 传送

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/75daa5/index.html b/pages/75daa5/index.html new file mode 100644 index 00000000..0038ebc5 --- /dev/null +++ b/pages/75daa5/index.html @@ -0,0 +1,240 @@ + + + + + + MongoDB 的聚合操作 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-21
目录

MongoDB 的聚合操作

# MongoDB 的聚合操作

聚合操作处理数据记录并返回计算结果。聚合操作将来自多个 document 的值分组，并可以对分组的数据执行各种操作以返回单个结果。 MongoDB 提供了三种执行聚合的方式：聚合管道，map-reduce 函数和单一目的聚合方法。

# Pipeline

# Pipeline 简介

MongoDB 的聚合框架以数据处理管道（Pipeline）的概念为模型。

MongoDB 通过 db.collection.aggregate() (opens new window) 方法支持聚合操作。并提供了 aggregate (opens new window) 命令来执行 pipeline。

MongoDB Pipeline 由多个阶段（stages (opens new window)）组成。每个阶段在 document 通过 pipeline 时都会对其进行转换。pipeline 阶段不需要为每个输入 document 都生成一个输出 document。例如，某些阶段可能会生成新 document 或过滤 document。

同一个阶段可以在 pipeline 中出现多次，但 $out (opens new window)、$merge (opens new window),和 $geoNear (opens new window) 阶段除外。所有可用 pipeline 阶段可以参考：Aggregation Pipeline Stages (opens new window)。

img

  • 第一阶段：$match (opens new window) 阶段按状态字段过滤 document，然后将状态等于“ A”的那些 document 传递到下一阶段。
  • 第二阶段：$group (opens new window) 阶段按 cust_id 字段对 document 进行分组，以计算每个唯一 cust_id 的金额总和。

最基本的管道阶段提供过滤器，其操作类似于查询和 document 转换（修改输出 document 形式）。

其他管道操作提供了用于按特定字段对 document 进行分组和排序的工具，以及用于汇总数组（包括 document 数组）内容的工具。另外，管道阶段可以将运算符用于诸如计算平均值或连接字符串之类的任务。

聚合管道也可以在分片 collection 上操作。

# Pipeline 优化

# 投影优化

Pipeline 可以确定是否仅需要 document 中必填字段即可获得结果。

# Pipeline 串行优化

（$project、$unset、$addFields、$set） + $match 串行优化

对于包含投影阶段（$project (opens new window) 或 $unset (opens new window) 或 $addFields (opens new window) 或 $set (opens new window)），且后续跟随着 $match (opens new window) 阶段的 Pipeline ，MongoDB 会将所有 $match (opens new window) 阶段中不需要在投影阶段中计算出的值的过滤器，移动一个在投影阶段之前的新 $match (opens new window) 阶段。

如果 Pipeline 包含多个投影阶段 和 / 或 $match (opens new window) 阶段，则 MongoDB 将为每个 $match (opens new window) 阶段执行此优化，将每个 $match (opens new window) 过滤器移动到该过滤器不依赖的所有投影阶段之前。

【示例】Pipeline 串行优化示例

优化前：

{ $addFields: {
+    maxTime: { $max: "$times" },
+    minTime: { $min: "$times" }
+} },
+{ $project: {
+    _id: 1, name: 1, times: 1, maxTime: 1, minTime: 1,
+    avgTime: { $avg: ["$maxTime", "$minTime"] }
+} },
+{ $match: {
+    name: "Joe Schmoe",
+    maxTime: { $lt: 20 },
+    minTime: { $gt: 5 },
+    avgTime: { $gt: 7 }
+} }
+

优化后：

{ $match: { name: "Joe Schmoe" } },
+{ $addFields: {
+    maxTime: { $max: "$times" },
+    minTime: { $min: "$times" }
+} },
+{ $match: { maxTime: { $lt: 20 }, minTime: { $gt: 5 } } },
+{ $project: {
+    _id: 1, name: 1, times: 1, maxTime: 1, minTime: 1,
+    avgTime: { $avg: ["$maxTime", "$minTime"] }
+} },
+{ $match: { avgTime: { $gt: 7 } } }
+

说明：

{ name: "Joe Schmoe" } 不需要计算任何投影阶段的值，所以可以放在最前面。

{ avgTime: { $gt: 7 } } 依赖 $project (opens new window) 阶段的 avgTime 字段，所以不能移动。

maxTime 和 minTime 字段被 $addFields (opens new window) 阶段所依赖，但自身不依赖其他，所以会新建一个 $match (opens new window) 阶段，并将其置于 $project (opens new window) 阶段之前。

# Pipeline 并行优化

如果可能，优化阶段会将 Pipeline 阶段合并到其前身。通常，合并发生在任意序列重新排序优化之后。

# $sort + $limit

当 $sort (opens new window) 在 $limit (opens new window) 之前时，如果没有中间阶段修改文档数量（例如 $unwind (opens new window)、$group (opens new window)），则优化程序可以将 $limit (opens new window) 合并到 $sort (opens new window) 中。如果有管道阶段更改了 $sort (opens new window) 和 $limit (opens new window) 阶段之间的文档数，则 MongoDB 不会将 $limit (opens new window) 合并到 $sort (opens new window) 中。

【示例】$sort + $limit

优化前：

{ $sort : { age : -1 } },
+{ $project : { age : 1, status : 1, name : 1 } },
+{ $limit: 5 }
+

优化后：

{
+    "$sort" : {
+       "sortKey" : {
+          "age" : -1
+       },
+       "limit" : NumberLong(5)
+    }
+},
+{ "$project" : {
+         "age" : 1,
+         "status" : 1,
+         "name" : 1
+  }
+}
+
# $limit + $limit

如果一个 $limit (opens new window) 紧随另一个 $limit (opens new window)，那么它们可以合并为一。

优化前：

{ $limit: 100 },
+{ $limit: 10 }
+

优化后：

{
+  $limit: 10
+}
+
# $skip + $skip

如果一个 $skip (opens new window) 紧随另一个 $skip (opens new window) ，那么它们可以合并为一。

优化前：

{ $skip: 5 },
+{ $skip: 2 }
+

优化后：

{
+  $skip: 7
+}
+
# $match + $match

如果一个 $skip (opens new window) 紧随另一个 $skip (opens new window) ，那么它们可以通过 $and (opens new window) 合并为一。

优化前：

{ $match: { year: 2014 } },
+{ $match: { status: "A" } }
+

优化后：

{
+  $match: {
+    $and: [{ year: 2014 }, { status: 'A' }]
+  }
+}
+
# $lookup + $unwind

如果一个 $unwind (opens new window) 紧随另一个 $lookup (opens new window)，并且 $unwind (opens new window) 在 $lookup (opens new window) 的 as 字段上运行时，优化程序可以将 $unwind (opens new window) 合并到 $lookup (opens new window) 阶段。这样可以避免创建较大的中间文档。

优化前：

{
+  $lookup: {
+    from: "otherCollection",
+    as: "resultingArray",
+    localField: "x",
+    foreignField: "y"
+  }
+},
+{ $unwind: "$resultingArray"}
+

优化后：

{
+  $lookup: {
+    from: "otherCollection",
+    as: "resultingArray",
+    localField: "x",
+    foreignField: "y",
+    unwinding: { preserveNullAndEmptyArrays: false }
+  }
+}
+

# Pipeline 限制

结果集中的每个文档均受 BSON 文档大小限制（当前为 16 MB）

Pipeline 的内存限制为 100 MB。

# Map-Reduce

聚合 pipeline 比 map-reduce 提供更好的性能和更一致的接口。

Map-reduce 是一种数据处理范式，用于将大量数据汇总为有用的聚合结果。为了执行 map-reduce 操作，MongoDB 提供了 mapReduce (opens new window) 数据库命令。

img

在上面的操作中，MongoDB 将 map 阶段应用于每个输入 document（即 collection 中与查询条件匹配的 document）。 map 函数分发出多个键-值对。对于具有多个值的那些键，MongoDB 应用 reduce 阶段，该阶段收集并汇总聚合的数据。然后，MongoDB 将结果存储在 collection 中。可选地，reduce 函数的输出可以通过 finalize 函数来进一步汇总聚合结果。

MongoDB 中的所有 map-reduce 函数都是 JavaScript，并在 mongod 进程中运行。 Map-reduce 操作将单个 collection 的 document 作为输入，并且可以在开始 map 阶段之前执行任意排序和限制。 mapReduce 可以将 map-reduce 操作的结果作为 document 返回，也可以将结果写入 collection。

# 单一目的聚合方法

MongoDB 支持一下单一目的的聚合操作：

所有这些操作都汇总了单个 collection 中的 document。尽管这些操作提供了对常见聚合过程的简单访问，但是它们相比聚合 pipeline 和 map-reduce，缺少灵活性和丰富的功能性。

img

# SQL 和 MongoDB 聚合对比

MongoDB pipeline 提供了许多等价于 SQL 中常见聚合语句的操作。

下表概述了常见的 SQL 聚合语句或函数和 MongoDB 聚合操作的映射表：

SQL Terms, Functions, and Concepts MongoDB Aggregation Operators
WHERE $match (opens new window)
GROUP BY $group (opens new window)
HAVING $match (opens new window)
SELECT $project (opens new window)
ORDER BY $sort (opens new window)
LIMIT $limit (opens new window)
SUM() $sum (opens new window)
COUNT() $sum (opens new window)$sortByCount (opens new window)
JOIN $lookup (opens new window)
SELECT INTO NEW_TABLE $out (opens new window)
MERGE INTO TABLE $merge (opens new window) (Available starting in MongoDB 4.2)
UNION ALL $unionWith (opens new window) (Available starting in MongoDB 4.4)

【示例】

db.orders.insertMany([
+  {
+    _id: 1,
+    cust_id: 'Ant O. Knee',
+    ord_date: new Date('2020-03-01'),
+    price: 25,
+    items: [
+      { sku: 'oranges', qty: 5, price: 2.5 },
+      { sku: 'apples', qty: 5, price: 2.5 }
+    ],
+    status: 'A'
+  },
+  {
+    _id: 2,
+    cust_id: 'Ant O. Knee',
+    ord_date: new Date('2020-03-08'),
+    price: 70,
+    items: [
+      { sku: 'oranges', qty: 8, price: 2.5 },
+      { sku: 'chocolates', qty: 5, price: 10 }
+    ],
+    status: 'A'
+  },
+  {
+    _id: 3,
+    cust_id: 'Busby Bee',
+    ord_date: new Date('2020-03-08'),
+    price: 50,
+    items: [
+      { sku: 'oranges', qty: 10, price: 2.5 },
+      { sku: 'pears', qty: 10, price: 2.5 }
+    ],
+    status: 'A'
+  },
+  {
+    _id: 4,
+    cust_id: 'Busby Bee',
+    ord_date: new Date('2020-03-18'),
+    price: 25,
+    items: [{ sku: 'oranges', qty: 10, price: 2.5 }],
+    status: 'A'
+  },
+  {
+    _id: 5,
+    cust_id: 'Busby Bee',
+    ord_date: new Date('2020-03-19'),
+    price: 50,
+    items: [{ sku: 'chocolates', qty: 5, price: 10 }],
+    status: 'A'
+  },
+  {
+    _id: 6,
+    cust_id: 'Cam Elot',
+    ord_date: new Date('2020-03-19'),
+    price: 35,
+    items: [
+      { sku: 'carrots', qty: 10, price: 1.0 },
+      { sku: 'apples', qty: 10, price: 2.5 }
+    ],
+    status: 'A'
+  },
+  {
+    _id: 7,
+    cust_id: 'Cam Elot',
+    ord_date: new Date('2020-03-20'),
+    price: 25,
+    items: [{ sku: 'oranges', qty: 10, price: 2.5 }],
+    status: 'A'
+  },
+  {
+    _id: 8,
+    cust_id: 'Don Quis',
+    ord_date: new Date('2020-03-20'),
+    price: 75,
+    items: [
+      { sku: 'chocolates', qty: 5, price: 10 },
+      { sku: 'apples', qty: 10, price: 2.5 }
+    ],
+    status: 'A'
+  },
+  {
+    _id: 9,
+    cust_id: 'Don Quis',
+    ord_date: new Date('2020-03-20'),
+    price: 55,
+    items: [
+      { sku: 'carrots', qty: 5, price: 1.0 },
+      { sku: 'apples', qty: 10, price: 2.5 },
+      { sku: 'oranges', qty: 10, price: 2.5 }
+    ],
+    status: 'A'
+  },
+  {
+    _id: 10,
+    cust_id: 'Don Quis',
+    ord_date: new Date('2020-03-23'),
+    price: 25,
+    items: [{ sku: 'oranges', qty: 10, price: 2.5 }],
+    status: 'A'
+  }
+])
+

SQL 和 MongoDB 聚合方式对比：

img

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#文档数据库#MongoDB#聚合
上次更新: 2023/06/29, 22:27:04
MongoDB 的 CRUD 操作
MongoDB 事务

+ ← + MongoDB 事务→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/77dfbe/index.html b/pages/77dfbe/index.html new file mode 100644 index 00000000..12193c68 --- /dev/null +++ b/pages/77dfbe/index.html @@ -0,0 +1,67 @@ + + + + + + Redis 集群 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-24
目录

Redis 集群

# Redis 集群

Redis 集群（Redis Cluster） (opens new window) 是 Redis 官方提供的分布式数据库方案。

既然是分布式，自然具备分布式系统的基本特性：可扩展、高可用、一致性。

  • Redis 集群通过划分 hash 槽来分区，进行数据分享。
  • Redis 集群采用主从模型，提供复制和故障转移功能，来保证 Redis 集群的高可用。
  • 根据 CAP 理论，Consistency、Availability、Partition tolerance 三者不可兼得，而 Redis 集群的选择是 AP。Redis 集群节点间采用异步通信方式，不保证强一致性，尽力达到最终一致性。

img

# 1. Redis Cluster 分区

# 1.1. 集群节点

Redis 集群由多个节点组成，节点刚启动时，彼此是相互独立的。节点通过握手（ CLUSTER MEET 命令）来将其他节点添加到自己所处的集群中。

向一个节点发送 CLUSTER MEET 命令，可以让当前节点与指定 IP、PORT 的节点进行握手，握手成功时，当前节点会将指定节点加入所在集群。

集群节点保存键值对以及过期时间的方式与单机 Redis 服务完全相同。

Redis 集群节点分为主节点（master）和从节点（slave），其中主节点用于处理槽，而从节点则用于复制某个主节点，并在被复制的主节点下线时，代替下线主节点继续处理命令请求。

# 1.2. 分配 Hash 槽

分布式存储需要解决的首要问题是把 整个数据集 按照 分区规则 映射到 多个节点 的问题，即把 数据集 划分到 多个节点 上，每个节点负责 整体数据 的一个 子集。

Redis 集群通过划分 hash 槽来将数据分区。Redis 集群通过分区的方式来保存数据库的键值对：集群的整个数据库被分为 16384 个哈希槽（slot），数据库中的每个键都属于这 16384 个槽的其中一个，集群中的每个节点可以处理 0 个或最多 16384 个槽。如果数据库中有任何一个槽没有得到处理，那么集群处于下线状态。

通过向节点发送 CLUSTER ADDSLOTS (opens new window) 命令，可以将一个或多个槽指派给节点负责。

> CLUSTER ADDSLOTS 1 2 3
+OK
+

集群中的每个节点负责一部分哈希槽，比如集群中有３个节点，则：

  • 节点Ａ存储的哈希槽范围是：0 – 5500
  • 节点Ｂ存储的哈希槽范围是：5501 – 11000
  • 节点Ｃ存储的哈希槽范围是：11001 – 16384

# 1.3. 寻址

当客户端向节点发送与数据库键有关的命令时，接受命令的节点会计算出命令要处理的数据库属于哪个槽，并检查这个槽是否指派给了自己：

  • 如果键所在的槽正好指派给了当前节点，那么当前节点直接执行命令。
  • 如果键所在的槽没有指派给当前节点，那么节点会向客户端返回一个 MOVED 错误，指引客户端重定向至正确的节点。

# 1.3.1. 计算键属于哪个槽

决定一个 key 应该分配到那个槽的算法是：计算该 key 的 CRC16 结果再模 16834。

HASH_SLOT = CRC16(KEY) mod 16384
+

当节点计算出 key 所属的槽为 i 之后，节点会根据以下条件判断槽是否由自己负责：

clusterState.slots[i] == clusterState.myself
+

# 1.3.2. MOVED 错误

当节点发现键所在的槽并非自己负责处理的时候，节点就会向客户端返回一个 MOVED 错误，指引客户端转向正在负责槽的节点。

MOVED 错误的格式为：

MOVED <slot> <ip>:<port>
+

个人理解：MOVED 这种操作有点类似 HTTP 协议中的重定向。

# 1.4. 重新分区

Redis 集群的重新分区操作可以将任意数量的已经指派给某个节点（源节点）的槽改为指派给另一个节点（目标节点），并且相关槽所属的键值对也会从源节点被移动到目标节点。

重新分区操作可以在线进行，在重新分区的过程中，集群不需要下线，并且源节点和目标节点都可以继续处理命令请求。

Redis 集群的重新分区操作由 Redis 集群管理软件 redis-trib 负责执行的，redis-trib 通过向源节点和目标节点发送命令来进行重新分区操作。

重新分区的实现原理如下图所示：

img

# 1.5. ASK 错误

ASK 错误与 MOVED 的区别在于：ASK 错误只是两个节点在迁移槽的过程中使用的一种临时措施，在客户端收到关于槽 X 的 ASK 错误之后，客户端只会在接下来的一次命令请求中将关于槽 X 的命令请求发送至 ASK 错误所指示的节点，但这种转向不会对客户端今后发送关于槽 X 的命令请求产生任何影响，客户端仍然会将关于槽 X 的命令请求发送至目前负责处理槽 X 的节点，除非 ASK 错误再次出现。

判断 ASK 错误的过程如下图所示：

img

# 2. Redis Cluster 故障转移

# 2.1. 复制

Redis 复制机制可以参考：Redis 复制

# 2.2. 故障检测

集群中每个节点都会定期向集群中的其他节点发送 PING 消息，以此来检测对方是否在线。

节点的状态信息可以分为：

  • 在线状态；

  • 下线状态（FAIL）;

  • 疑似下线状态（PFAIL），即在规定的时间内，没有应答 PING 消息；

# 2.3. 故障转移

  1. 下线主节点的所有从节点中，会有一个从节点被选中。
  2. 被选中的从节点会执行 SLAVEOF no one 命令，成为新的主节点。
  3. 新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽全部指派给自己。
  4. 新的主节点向集群广播一条 PONG 消息，告知其他节点这个从节点已变成主节点。

# 2.4. 选举新的主节点

Redis 集群选举新的主节点流程基于共识算法：Raft (opens new window)

# 3. Redis Cluster 通信

集群中的节点通过发送和接收消息来进行通信。

Redis 集群节点发送的消息主要有以下五种：

  • MEET - 请求接收方加入发送方所在的集群。
  • PING - 集群中每个节点每隔一段时间（默认为一秒）从已知节点列表中随机选出五个节点，然后对这五个节点中最久没联系的节点发送 PING 消息，以此检测被选中的节点是否在线。
  • PONG - 当接收方收到发送方发来的 MEET 消息或 PING 消息时，会返回一条 PONG 消息作为应答。
  • FAIL - 当一个主节点 A 判断另一个主节点 B 已经进入 FAIL 状态时，节点 A 会向集群广播一条关于节点 B 的 FAIL 消息，所有收到这条消息的节点都会立即将节点 B 标记为已下线。
  • PUBLISH - 当节点收到一个 PUBLISH 命令时，节点会执行这个命令，并向集群广播一条 PUBLISH 消息，所有接受到这条消息的节点都会执行相同的 PUBLISH 命令。

# 4. Redis Cluster 应用

# 4.1. 集群功能限制

Redis 集群相对 单机，存在一些功能限制，需要 开发人员 提前了解，在使用时做好规避。

  • key 批量操作 支持有限：类似 mset、mget 操作，目前只支持对具有相同 slot 值的 key 执行 批量操作。对于 映射为不同 slot 值的 key 由于执行 mget、mget 等操作可能存在于多个节点上，因此不被支持。

  • key 事务操作 支持有限：只支持 多 key 在 同一节点上 的 事务操作，当多个 key 分布在 不同 的节点上时 无法 使用事务功能。

  • key 作为 数据分区 的最小粒度，不能将一个 大的键值 对象如 hash、list 等映射到 不同的节点。

  • 不支持 多数据库空间：单机 下的 Redis 可以支持 16 个数据库（db0 ~ db15），集群模式 下只能使用 一个 数据库空间，即 db0。

  • 复制结构 只支持一层：从节点 只能复制 主节点，不支持 嵌套树状复制 结构。

# 4.2. 集群规模限制

Redis Cluster 的优点是易于使用。分区、主从复制、弹性扩容这些功能都可以做到自动化，通过简单的部署就可以获得一个大容量、高可靠、高可用的 Redis 集群，并且对于应用来说，近乎于是透明的。

所以，Redis Cluster 非常适合构建中小规模 Redis 集群，这里的中小规模指的是，大概几个到几十个节点这样规模的 Redis 集群。

但是 Redis Cluster 不太适合构建超大规模集群，主要原因是，它采用了去中心化的设计。

Redis 的每个节点上，都保存了所有槽和节点的映射关系表，客户端可以访问任意一个节点，再通过重定向命令，找到数据所在的那个节点。那么，这个映射关系表是如何更新的呢？Redis Cluster 采用了一种去中心化的流言 (Gossip) 协议来传播集群配置的变化。

Gossip 协议的优点是去中心化；缺点是传播速度慢，并且是集群规模越大，传播的越慢。

# 4.3. 集群配置

我们后面会部署一个 Redis 集群作为例子，在那之前，先介绍一下集群在 redis.conf 中的参数。

  • cluster-enabled <yes/no> - 如果配置”yes”则开启集群功能，此 redis 实例作为集群的一个节点，否则，它是一个普通的单一的 redis 实例。
  • cluster-config-file <filename> - 注意：虽然此配置的名字叫“集群配置文件”，但是此配置文件不能人工编辑，它是集群节点自动维护的文件，主要用于记录集群中有哪些节点、他们的状态以及一些持久化参数等，方便在重启时恢复这些状态。通常是在收到请求之后这个文件就会被更新。
  • cluster-node-timeout <milliseconds> - 这是集群中的节点能够失联的最大时间，超过这个时间，该节点就会被认为故障。如果主节点超过这个时间还是不可达，则用它的从节点将启动故障迁移，升级成主节点。注意，任何一个节点在这个时间之内如果还是没有连上大部分的主节点，则此节点将停止接收任何请求。
  • cluster-slave-validity-factor <factor> - 如果设置成０，则无论从节点与主节点失联多久，从节点都会尝试升级成主节点。如果设置成正数，则 cluster-node-timeout 乘以 cluster-slave-validity-factor 得到的时间，是从节点与主节点失联后，此从节点数据有效的最长时间，超过这个时间，从节点不会启动故障迁移。假设 cluster-node-timeout=5，cluster-slave-validity-factor=10，则如果从节点跟主节点失联超过 50 秒，此从节点不能成为主节点。注意，如果此参数配置为非 0，将可能出现由于某主节点失联却没有从节点能顶上的情况，从而导致集群不能正常工作，在这种情况下，只有等到原来的主节点重新回归到集群，集群才恢复运作。
  • cluster-migration-barrier <count> - 主节点需要的最小从节点数，只有达到这个数，主节点失败时，它从节点才会进行迁移。更详细介绍可以看本教程后面关于副本迁移到部分。
  • cluster-require-full-coverage <yes/no> - 在部分 key 所在的节点不可用时，如果此参数设置为”yes”(默认值), 则整个集群停止接受操作；如果此参数设置为”no”，则集群依然为可达节点上的 key 提供读操作。

# 5. 其他 Redis 集群方案

Redis Cluster 不太适合用于大规模集群，所以，如果要构建超大 Redis 集群，需要选择替代方案。一般有三种方案类型：

  • 客户端分区方案
  • 代理分区方案
  • 查询路由方案

# 5.1. 客户端分区方案

客户端 就已经决定数据会被 存储 到哪个 Redis 节点或者从哪个 Redis 节点 读取数据。其主要思想是采用 哈希算法 将 Redis 数据的 key 进行散列，通过 hash 函数，特定的 key会 映射 到特定的 Redis 节点上。

客户端分区方案 的代表为 Redis Sharding，Redis Sharding 是 Redis Cluster 出来之前，业界普遍使用的 Redis 多实例集群 方法。Java 的 Redis 客户端驱动库 Jedis (opens new window)，支持 Redis Sharding 功能，即 ShardedJedis 以及 结合缓存池 的 ShardedJedisPool。

  • 优点：不使用 第三方中间件，分区逻辑 可控，配置 简单，节点之间无关联，容易 线性扩展，灵活性强。

  • 缺点：客户端 无法 动态增删 服务节点，客户端需要自行维护 分发逻辑，客户端之间 无连接共享，会造成 连接浪费。

# 5.2. 代理分区方案

客户端 发送请求到一个 代理组件，代理 解析 客户端 的数据，并将请求转发至正确的节点，最后将结果回复给客户端。

  • 优点：简化 客户端 的分布式逻辑，客户端 透明接入，切换成本低，代理的 转发 和 存储 分离。
  • 缺点：多了一层 代理层，加重了 架构部署复杂度 和 性能损耗。

代理分区 主流实现的有方案有 Twemproxy (opens new window) 和 Codis (opens new window)。

# 5.2.1. Twemproxy

Twemproxy (opens new window) 也叫 nutcraker，是 Twitter 开源的一个 Redis 和 Memcache 的 中间代理服务器 程序。

Twemproxy (opens new window) 作为 代理，可接受来自多个程序的访问，按照 路由规则，转发给后台的各个 Redis 服务器，再原路返回。Twemproxy (opens new window) 存在 单点故障 问题，需要结合 Lvs 和 Keepalived 做 高可用方案。

  • 优点：应用范围广，稳定性较高，中间代理层 高可用。
  • 缺点：无法平滑地 水平扩容/缩容，无 可视化管理界面，运维不友好，出现故障，不能 自动转移。

# 5.2.2. Codis

Codis (opens new window) 是一个 分布式 Redis 解决方案，对于上层应用来说，连接 Codis-Proxy 和直接连接 原生的 Redis-Server 没有的区别。Codis (opens new window) 底层会 处理请求的转发，不停机的进行 数据迁移 等工作。Codis (opens new window) 采用了无状态的 代理层，对于 客户端 来说，一切都是透明的。

  • 优点：实现了上层 Proxy 和底层 Redis 的 高可用，数据分区 和 自动平衡，提供 命令行接口 和 RESTful API，提供 监控 和 管理 界面，可以动态 添加 和 删除 Redis 节点。

  • 缺点：部署架构 和 配置 复杂，不支持 跨机房 和 多租户，不支持 鉴权管理。

# 5.3. 查询路由方案

客户端随机地 请求任意一个 Redis 实例，然后由 Redis 将请求 转发 给 正确 的 Redis 节点。Redis Cluster 实现了一种 混合形式 的 查询路由，但并不是 直接 将请求从一个 Redis 节点 转发 到另一个 Redis 节点，而是在 客户端 的帮助下直接 重定向（ redirected）到正确的 Redis 节点。

  • 优点：去中心化，数据按照 槽 存储分布在多个 Redis 实例上，可以平滑的进行节点 扩容/缩容，支持 高可用 和 自动故障转移，运维成本低。

  • 缺点：重度依赖 Redis-trib 工具，缺乏 监控管理，需要依赖 Smart Client (维护连接，缓存路由表，MultiOp 和 Pipeline 支持)。Failover 节点的 检测过慢，不如有 中心节点 的集群及时（如 ZooKeeper）。Gossip 消息采用广播方式，集群规模越大，开销越大。无法根据统计区分 冷热数据。

# 6. 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#KV数据库#Redis#集群
上次更新: 2023/06/29, 22:27:04
Redis 哨兵
Redis 实战

+ ← + Redis 实战→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/7ab03c/index.html b/pages/7ab03c/index.html new file mode 100644 index 00000000..2436b918 --- /dev/null +++ b/pages/7ab03c/index.html @@ -0,0 +1,109 @@ + + + + + + HBase 快速入门 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-02-10
目录

HBase 快速入门

# HBase 快速入门

# HBase 简介

# 为什么需要 HBase

在介绍 HBase 之前，我们不妨先了解一下为什么需要 HBase，或者说 HBase 是为了达到什么目的而产生。

在 HBase 诞生之前，Hadoop 可以通过 HDFS 来存储结构化、半结构甚至非结构化的数据，它是传统数据库的补充，是海量数据存储的最佳方法，它针对大文件的存储，批量访问和流式访问都做了优化，同时也通过多副本解决了容灾问题。

Hadoop 的缺陷在于：它只能执行批处理，并且只能以顺序方式访问数据。这意味着即使是最简单的工作，也必须搜索整个数据集，即：Hadoop 无法实现对数据的随机访问。实现数据的随机访问是传统的关系型数据库所擅长的，但它们却不能用于海量数据的存储。在这种情况下，必须有一种新的方案来同时解决海量数据存储和随机访问的问题，HBase 就是其中之一 (HBase，Cassandra，couchDB，Dynamo 和 MongoDB 都能存储海量数据并支持随机访问)。

注：数据结构分类：

  • 结构化数据：即以关系型数据库表形式管理的数据；
  • 半结构化数据：非关系模型的，有基本固定结构模式的数据，例如日志文件、XML 文档、JSON 文档、Email 等；
  • 非结构化数据：没有固定模式的数据，如 WORD、PDF、PPT、EXL，各种格式的图片、视频等。

# 什么是 HBase

HBase 是一个构建在 HDFS（Hadoop 文件系统）之上的列式数据库。

HBase 是一种类似于 Google’s Big Table 的数据模型，它是 Hadoop 生态系统的一部分，它将数据存储在 HDFS 上，客户端可以通过 HBase 实现对 HDFS 上数据的随机访问。

img

HBase 的核心特性如下：

  • 分布式
    • 伸缩性：支持通过增减机器进行水平扩展，以提升整体容量和性能
    • 高可用：支持 RegionServers 之间的自动故障转移
    • 自动分区：Region 分散在集群中，当行数增长的时候，Region 也会自动的分区再均衡
  • 超大数据集：HBase 被设计用来读写超大规模的数据集（数十亿行至数百亿行的表）
  • 支持结构化、半结构化和非结构化的数据：由于 HBase 基于 HDFS 构建，所以和 HDFS 一样，支持结构化、半结构化和非结构化的数据
  • 非关系型数据库
    • 不支持标准 SQL 语法
    • 没有真正的索引
    • 不支持复杂的事务：只支持行级事务，即单行数据的读写都是原子性的

HBase 的其他特性

  • 读写操作遵循强一致性
  • 过滤器支持谓词下推
  • 易于使用的 Java 客户端 API
  • 它支持线性和模块化可扩展性。
  • HBase 表支持 Hadoop MapReduce 作业的便捷基类
  • 很容易使用 Java API 进行客户端访问
  • 为实时查询提供块缓存 BlockCache 和布隆过滤器
  • 它通过服务器端过滤器提供查询谓词下推

# 什么时候使用 HBase

根据上一节对于 HBase 特性的介绍，我们可以梳理出 HBase 适用、不适用的场景：

HBase 不适用场景：

  • 需要索引
  • 需要复杂的事务
  • 数据量较小（比如：数据量不足几百万行）

HBase 适用场景：

  • 能存储海量数据并支持随机访问（比如：数据量级达到十亿级至百亿级）
  • 存储结构化、半结构化数据
  • 硬件资源充足

一言以蔽之——HBase 适用的场景是：实时地随机访问超大数据集。

HBase 的典型应用场景

  • 存储监控数据
  • 存储用户/车辆 GPS 信息
  • 存储用户行为数据
  • 存储各种日志数据，如：访问日志、操作日志、推送日志等。
  • 存储短信、邮件等消息类数据
  • 存储网页数据

# HBase 数据模型简介

前面已经提及，HBase 是一个列式数据库，其数据模型和关系型数据库有所不同。其数据模型的关键术语如下：

  • Table：HBase 表由多行组成。
  • Row：HBase 中的一行由一个行键和一个或多个列以及与之关联的值组成。 行在存储时按行键的字母顺序排序。 为此，行键的设计非常重要。 目标是以相关行彼此靠近的方式存储数据。 常见的行键模式是网站域。 如果您的行键是域，您应该将它们反向存储（org.apache.www、org.apache.mail、org.apache.jira）。 这样，所有 Apache 域在表中彼此靠近，而不是根据子域的第一个字母展开。
  • Column：HBase 中的列由列族和列限定符组成，它们由 :（冒号）字符分隔。
  • Column Family：通常出于性能原因，列族在物理上将一组列及其值放在一起。 每个列族都有一组存储属性，例如它的值是否应该缓存在内存中，它的数据是如何压缩的，它的行键是如何编码的，等等。 表中的每一行都有相同的列族，尽管给定的行可能不在给定的列族中存储任何内容。
  • 列限定符：将列限定符添加到列族以提供给定数据片段的索引。 给定列族内容，列限定符可能是 content:html，另一个可能是 content:pdf。 尽管列族在表创建时是固定的，但列限定符是可变的，并且行之间可能有很大差异。
  • Cell：单元格是行、列族和列限定符的组合，包含一个值和一个时间戳，代表值的版本。
  • Timestamp：时间戳写在每个值旁边，是给定版本值的标识符。 默认情况下，时间戳表示写入数据时 RegionServer 上的时间，但您可以在将数据放入单元格时指定不同的时间戳值。

img

# 特性比较

# HBase vs. RDBMS

RDBMS HBase
RDBMS 有它的模式，描述表的整体结构的约束 HBase 无模式，它不具有固定列模式的概念；仅定义列族
支持的文件系统有 FAT、NTFS 和 EXT 支持的文件系统只有 HDFS
使用提交日志来存储日志 使用预写日志 (WAL) 来存储日志
使用特定的协调系统来协调集群 使用 ZooKeeper 来协调集群
存储的都是中小规模的数据表 存储的是超大规模的数据表，并且适合存储宽表
通常支持复杂的事务 仅支持行级事务
适用于结构化数据 适用于半结构化、结构化数据
使用主键 使用 row key

# HBase vs. HDFS

HDFS HBase
HDFS 提供了一个用于分布式存储的文件系统。 HBase 提供面向表格列的数据存储。
HDFS 为大文件提供优化存储。 HBase 为表格数据提供了优化。
HDFS 使用块文件。 HBase 使用键值对数据。
HDFS 数据模型不灵活。 HBase 提供了一个灵活的数据模型。
HDFS 使用文件系统和处理框架。 HBase 使用带有内置 Hadoop MapReduce 支持的表格存储。
HDFS 主要针对一次写入多次读取进行了优化。 HBase 针对读/写许多进行了优化。

# 行式数据库 vs. 列式数据库

行式数据库 列式数据库
对于添加/修改操作更高效 对于读取操作更高效
读取整行数据 仅读取必要的列数据
最适合在线事务处理系统（OLTP） 不适合在线事务处理系统（OLTP）
将行数据存储在连续的页内存中 将列数据存储在非连续的页内存中

列式数据库的优点：

  • 支持数据压缩
  • 支持快速数据检索
  • 简化了管理和配置
  • 有利于聚合查询（例如 COUNT、SUM、AVG、MIN 和 MAX）的高性能
  • 分区效率很高，因为它提供了自动分片机制的功能，可以将较大的区域分配给较小的区域

列式数据库的缺点：

  • JOIN 查询和来自多个表的数据未优化
  • 必须为频繁的删除和更新创建拆分，因此降低了存储效率
  • 由于非关系数据库的特性，分区和索引的设计非常困难

# HBase 安装

# HBase Hello World 示例

  1. 连接 HBase

    在 HBase 安装目录的 /bin 目录下执行 hbase shell 命令进入 HBase 控制台。

    $ ./bin/hbase shell
+hbase(main):001:0>
+

  2. 输入 help 可以查看 HBase Shell 命令。

  3. 创建表

    可以使用 create 命令创建一张新表。必须要指定表名和 Column Family。

    hbase(main):001:0> create 'test', 'cf'
+0 row(s) in 0.4170 seconds
+
+=> Hbase::Table - test
+

  4. 列出表信息

    使用 list 命令来确认新建的表已存在。

    hbase(main):002:0> list 'test'
+TABLE
+test
+1 row(s) in 0.0180 seconds
+
+=> ["test"]
+

    可以使用 describe 命令可以查看表的细节信息，包括配置信息

    hbase(main):003:0> describe 'test'
+Table test is ENABLED
+test
+COLUMN FAMILIES DESCRIPTION
+{NAME => 'cf', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE =>
+'false', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0', REPLICATION_SCOPE => '0', BLOOMFILTER => 'ROW', CACHE_INDEX_ON_WRITE => 'f
+alse', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE => 'true', BLOCKSIZE
+ => '65536'}
+1 row(s)
+Took 0.9998 seconds
+

  5. 向表中写数据

    可以使用 put 命令向 HBase 表中写数据。

    hbase(main):003:0> put 'test', 'row1', 'cf:a', 'value1'
+0 row(s) in 0.0850 seconds
+
+hbase(main):004:0> put 'test', 'row2', 'cf:b', 'value2'
+0 row(s) in 0.0110 seconds
+
+hbase(main):005:0> put 'test', 'row3', 'cf:c', 'value3'
+0 row(s) in 0.0100 seconds
+

  6. 一次性扫描表的所有数据

    使用 scan 命令来扫描表数据。

    hbase(main):006:0> scan 'test'
+ROW                                      COLUMN+CELL
+ row1                                    column=cf:a, timestamp=1421762485768, value=value1
+ row2                                    column=cf:b, timestamp=1421762491785, value=value2
+ row3                                    column=cf:c, timestamp=1421762496210, value=value3
+3 row(s) in 0.0230 seconds
+

  7. 查看一行数据

    使用 get 命令可以查看一行表数据。

    hbase(main):007:0> get 'test', 'row1'
+COLUMN                                   CELL
+ cf:a                                    timestamp=1421762485768, value=value1
+1 row(s) in 0.0350 seconds
+

  8. 禁用表

    如果想要删除表或修改表设置，必须先使用 disable 命令禁用表。如果想再次启用表，可以使用 enable 命令。

    hbase(main):008:0> disable 'test'
+0 row(s) in 1.1820 seconds
+
+hbase(main):009:0> enable 'test'
+0 row(s) in 0.1770 seconds
+

  9. 删除表

    使用 drop 命令可以删除表。

    hbase(main):011:0> drop 'test'
+0 row(s) in 0.1370 seconds
+

  10. 退出 HBase Shell

    使用 quit 命令，就能退出 HBase Shell 控制台。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#列式数据库#大数据#HBase
上次更新: 2023/06/29, 22:27:04
Redis 运维
HBase 数据模型

+ ← + HBase 数据模型→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/7b0caf/index.html b/pages/7b0caf/index.html new file mode 100644 index 00000000..3e3a319b --- /dev/null +++ b/pages/7b0caf/index.html @@ -0,0 +1,62 @@ + + + + + + Mysql 常见问题 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-12
目录

Mysql 常见问题

# Mysql 常见问题

📦 本文以及示例源码已归档在 db-tutorial (opens new window)

# 为什么表数据删掉一半，表文件大小不变

【问题】数据库占用空间太大，我把一个最大的表删掉了一半的数据，怎么表文件的大小还是没变？

表数据既可以存在共享表空间里，也可以是单独的文件。这个行为是由参数 innodb_file_per_table 控制的：

  1. 这个参数设置为 OFF 表示的是，表的数据放在系统共享表空间，也就是跟数据字典放在一起；
  2. 这个参数设置为 ON 表示的是，每个 InnoDB 表数据存储在一个以 .ibd 为后缀的文件中。

从 MySQL 5.6.6 版本开始，它的默认值就是 ON 了。

我建议你不论使用 MySQL 的哪个版本，都将这个值设置为 ON。因为，一个表单独存储为一个文件更容易管理，而且在你不需要这个表的时候，通过 drop table 命令，系统就会直接删除这个文件。而如果是放在共享表空间中，即使表删掉了，空间也是不会回收的。

所以，将 innodb_file_per_table 设置为 ON，是推荐做法，我们接下来的讨论都是基于这个设置展开的。

我们在删除整个表的时候，可以使用 drop table 命令回收表空间。但是，我们遇到的更多的删除数据的场景是删除某些行，这时就遇到了我们文章开头的问题：表中的数据被删除了，但是表空间却没有被回收。

插入和删除操作可能会造成空洞。

  • 插入时，如果插入位置所在页已满，需要申请新页面。
  • 删除时，不会删除所在页，而是将记录在页面的位置标记为可重用。

所以，如果能够把这些空洞去掉，就能达到收缩表空间的目的。

要达到收缩空洞的目的，可以使用重建表的方式。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#Mysql#FAQ
上次更新: 2023/06/29, 22:27:04
Mysql 配置
PostgreSQL 应用指南

+ ← + PostgreSQL 应用指南→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/7bf7f7/index.html b/pages/7bf7f7/index.html new file mode 100644 index 00000000..d82a1247 --- /dev/null +++ b/pages/7bf7f7/index.html @@ -0,0 +1,59 @@ + + + + + + Elastic 技术栈 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-04-11
目录

Elastic 技术栈

# Elastic 技术栈

Elastic 技术栈通常被用来作为日志采集、检索、可视化的解决方案。

ELK 是 elastic 公司旗下三款产品 Elasticsearch (opens new window) 、Logstash (opens new window) 、Kibana (opens new window) 的首字母组合。

Logstash (opens new window) 传输和处理你的日志、事务或其他数据。

Kibana (opens new window) 将 Elasticsearch 的数据分析并渲染为可视化的报表。

Elastic 技术栈，在 ELK 的基础上扩展了一些新的产品，如：Beats (opens new window) 、X-Pack (opens new window) 。

# 📖 内容

# 📚 资料

# 🚪 传送

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elastic
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/7c067f/index.html b/pages/7c067f/index.html new file mode 100644 index 00000000..802e9417 --- /dev/null +++ b/pages/7c067f/index.html @@ -0,0 +1,117 @@ + + + + + + Filebeat 运维 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-16
目录

Filebeat 运维

# Filebeat 运维

Beats 平台集合了多种单一用途数据采集器。它们从成百上千或成千上万台机器和系统向 Logstash 或 Elasticsearch 发送数据。

因为我只接触过 Filebeat，所有本文仅介绍 Filebeat 的日常运维。

# 1. Filebeat 安装

# 1.1. 环境要求

版本：Elastic Stack 7.4

# 1.2. 安装步骤

Unix / Linux 系统建议使用下面方式安装，因为比较通用。

wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.1.1-linux-x86_64.tar.gz
+tar -zxf filebeat-6.1.1-linux-x86_64.tar.gz
+

更多内容可以参考：filebeat-installation (opens new window)

# 2. Filebeat 配置

首先，必须要知道的是：filebeat.yml 是 filebeat 的配置文件。其路径会因为你安装方式而有所不同。

Beat 所有系列产品的配置文件都基于 YAML (opens new window) 格式，FileBeat 当然也不例外。

更多 filebeat 配置内容可以参考：配置 filebeat (opens new window)

更多 filebeat.yml 文件格式内容可以参考：filebeat.yml 文件格式 (opens new window)

filebeat.yml 部分配置示例：

filebeat:
+  prospectors:
+    - type: log
+      paths:
+        - /var/log/*.log
+      multiline:
+        pattern: '^['
+        match: after
+

# 2.1. 重要配置项

下面我将列举 Filebeat 的较为重要的配置项。

如果想了解更多配置信息，可以参考：

更多 filebeat 配置内容可以参考：配置 filebeat (opens new window)

更多 filebeat.yml 文件格式内容可以参考：filebeat.yml 文件格式 (opens new window)

# 2.1.1. filebeat.prospectors

（文件监视器）用于指定需要关注的文件。

示例

filebeat.prospectors:
+  - type: log
+    enabled: true
+    paths:
+      - /var/log/*.log
+

# 2.1.2. output.elasticsearch

如果你希望使用 filebeat 直接向 elasticsearch 输出数据，需要配置 output.elasticsearch 。

示例

output.elasticsearch:
+  hosts: ['192.168.1.42:9200']
+

# 2.1.3. output.logstash

如果你希望使用 filebeat 向 logstash 输出数据，然后由 logstash 再向 elasticsearch 输出数据，需要配置 output.logstash。

注意

相比于向 elasticsearch 输出数据，个人更推荐向 logstash 输出数据。

因为 logstash 和 filebeat 一起工作时，如果 logstash 忙于处理数据，会通知 FileBeat 放慢读取速度。一旦拥塞得到解决，FileBeat 将恢复到原来的速度并继续传播。这样，可以减少管道超负荷的情况。

示例

output.logstash:
+  hosts: ['127.0.0.1:5044']
+

此外，还需要在 logstash 的配置文件（如 logstash.conf）中指定 beats input 插件：

input {
+  beats {
+    port => 5044 # 此端口需要与 filebeat.yml 中的端口相同
+  }
+}
+
+# The filter part of this file is commented out to indicate that it is
+# optional.
+# filter {
+#
+# }
+
+output {
+  elasticsearch {
+    hosts => "localhost:9200"
+    manage_template => false
+    index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}"
+    document_type => "%{[@metadata][type]}"
+  }
+}
+

# 2.1.4. setup.kibana

如果打算使用 Filebeat 提供的 Kibana 仪表板，需要配置 setup.kibana 。

示例

setup.kibana:
+  host: 'localhost:5601'
+

# 2.1.5. setup.template.settings

在 Elasticsearch 中，索引模板 (opens new window)用于定义设置和映射，以确定如何分析字段。

在 Filebeat 中，setup.template.settings 用于配置索引模板。

Filebeat 推荐的索引模板文件由 Filebeat 软件包安装。如果您接受 filebeat.yml 配置文件中的默认配置，Filebeat 在成功连接到 Elasticsearch 后自动加载模板。

您可以通过在 Filebeat 配置文件中配置模板加载选项来禁用自动模板加载，或加载自己的模板。您还可以设置选项来更改索引和索引模板的名称。

参考

更多内容可以参考：filebeat-template (opens new window)

说明

如无必要，使用 Filebeat 配置文件中的默认索引模板即可。

# 2.1.6. setup.dashboards

Filebeat 附带了示例 Kibana 仪表板。在使用仪表板之前，您需要创建索引模式 filebeat- *，并将仪表板加载到 Kibana 中。为此，您可以运行 setup 命令或在 filebeat.yml 配置文件中配置仪表板加载。

为了在 Kibana 中加载 Filebeat 的仪表盘，需要在 filebeat.yml 配置中启动开关：

setup.dashboards.enabled: true
+

参考

更多内容可以参考：configuration-dashboards (opens new window)

# 3. Filebeat 命令

filebeat 提供了一系列命令来完成各种功能。

执行命令方式：

./filebeat COMMAND
+

参考

更多内容可以参考：command-line-options (opens new window)

说明

个人认为命令行没有必要一一掌握，因为绝大部分功能都可以通过配置来完成。且通过命令行指定功能这种方式要求每次输入同样参数，不利于固化启动方式。

最重要的当然是启动命令 run 了。

示例 指定配置文件启动

./filebeat run -e -c filebeat.yml -d "publish"
+./filebeat -e -c filebeat.yml -d "publish" # run 可以省略
+

# 4. Filebeat 模块

Filebeat (opens new window) 和 Metricbeat (opens new window) 内部集成了一系列模块，用以简化常见日志格式（例如 NGINX、Apache 或诸如 Redis 或 Docker 等系统指标）的收集、解析和可视化过程。

  • 配置 elasticsearch 和 kibana
output.elasticsearch:
+  hosts: ["myEShost:9200"]
+  username: "elastic"
+  password: "elastic"
+setup.kibana:
+  host: "mykibanahost:5601"
+  username: "elastic"
+  password: "elastic
+

username 和 password 是可选的，如果不需要认证则不填。

  • 初始化环境

执行下面命令，filebeat 会加载推荐索引模板。

./filebeat setup -e
+
  • 指定模块

执行下面命令，指定希望加载的模块。

./filebeat -e --modules system,nginx,mysql
+

更多内容可以参考：

# 5. 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elastic#Filebeat
上次更新: 2023/06/29, 22:27:04
Elastic 技术栈之 Filebeat
Elastic 技术栈之 Kibana

+ ← + Elastic 技术栈之 Kibana→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/7efbac/index.html b/pages/7efbac/index.html new file mode 100644 index 00000000..e0ac3fa3 --- /dev/null +++ b/pages/7efbac/index.html @@ -0,0 +1,199 @@ + + + + + + MongoDB 的 CRUD 操作 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-25
目录

MongoDB 的 CRUD 操作

# MongoDB 的 CRUD 操作

# 一、基本 CRUD 操作

MongoDB 的 CRUD 操作是针对 document 的读写操作。

# Create 操作

MongoDB 提供以下操作向一个 collection 插入 document

注：以上操作都是原子操作。

img

插入操作的特性：

  • MongoDB 中的所有写操作都是单个文档级别的原子操作。
  • 如果要插入的 collection 当前不存在，则插入操作会自动创建 collection。
  • 在 MongoDB 中，存储在集合中的每个文档都需要一个唯一的 _id (opens new window) 字段作为主键。如果插入的文档省略 _id 字段，则 MongoDB 驱动程序会自动为 _id 字段生成 ObjectId。
  • 可以 MongoDB 写入操作的确认级别来控制写入行为。

【示例】插入一条 document 示例

db.inventory.insertOne({
+  item: 'canvas',
+  qty: 100,
+  tags: ['cotton'],
+  size: { h: 28, w: 35.5, uom: 'cm' }
+})
+

【示例】插入多条 document 示例

db.inventory.insertMany([
+  {
+    item: 'journal',
+    qty: 25,
+    tags: ['blank', 'red'],
+    size: { h: 14, w: 21, uom: 'cm' }
+  },
+  {
+    item: 'mat',
+    qty: 85,
+    tags: ['gray'],
+    size: { h: 27.9, w: 35.5, uom: 'cm' }
+  },
+  {
+    item: 'mousepad',
+    qty: 25,
+    tags: ['gel', 'blue'],
+    size: { h: 19, w: 22.85, uom: 'cm' }
+  }
+])
+

# Read 操作

MongoDB 提供 db.collection.find() (opens new window) 方法来检索 document。

img

# Update 操作

MongoDB 提供以下操作来更新 collection 中的 document

语法格式：

img

【示例】插入测试数据

db.inventory.insertMany([
+  {
+    item: 'canvas',
+    qty: 100,
+    size: { h: 28, w: 35.5, uom: 'cm' },
+    status: 'A'
+  },
+  { item: 'journal', qty: 25, size: { h: 14, w: 21, uom: 'cm' }, status: 'A' },
+  { item: 'mat', qty: 85, size: { h: 27.9, w: 35.5, uom: 'cm' }, status: 'A' },
+  {
+    item: 'mousepad',
+    qty: 25,
+    size: { h: 19, w: 22.85, uom: 'cm' },
+    status: 'P'
+  },
+  {
+    item: 'notebook',
+    qty: 50,
+    size: { h: 8.5, w: 11, uom: 'in' },
+    status: 'P'
+  },
+  { item: 'paper', qty: 100, size: { h: 8.5, w: 11, uom: 'in' }, status: 'D' },
+  {
+    item: 'planner',
+    qty: 75,
+    size: { h: 22.85, w: 30, uom: 'cm' },
+    status: 'D'
+  },
+  {
+    item: 'postcard',
+    qty: 45,
+    size: { h: 10, w: 15.25, uom: 'cm' },
+    status: 'A'
+  },
+  {
+    item: 'sketchbook',
+    qty: 80,
+    size: { h: 14, w: 21, uom: 'cm' },
+    status: 'A'
+  },
+  {
+    item: 'sketch pad',
+    qty: 95,
+    size: { h: 22.85, w: 30.5, uom: 'cm' },
+    status: 'A'
+  }
+])
+

【示例】更新一条 document

db.inventory.updateOne(
+  { item: 'paper' },
+  {
+    $set: { 'size.uom': 'cm', status: 'P' },
+    $currentDate: { lastModified: true }
+  }
+)
+

【示例】更新多条 document

db.inventory.updateMany(
+  { qty: { $lt: 50 } },
+  {
+    $set: { 'size.uom': 'in', status: 'P' },
+    $currentDate: { lastModified: true }
+  }
+)
+

【示例】替换一条 document

db.inventory.replaceOne(
+  { item: 'paper' },
+  {
+    item: 'paper',
+    instock: [
+      { warehouse: 'A', qty: 60 },
+      { warehouse: 'B', qty: 40 }
+    ]
+  }
+)
+

更新操作的特性：

  • MongoDB 中的所有写操作都是单个文档级别的原子操作。
  • 一旦设置了，就无法更新或替换 _id (opens new window) 字段。
  • 除以下情况外，MongoDB 会在执行写操作后保留文档字段的顺序： +
    • _id 字段始终是文档中的第一个字段。
    • 包括重命名字段名称的更新可能导致文档中字段的重新排序。
  • 如果更新操作中包含 upsert : true 并且没有 document 匹配过滤器，MongoDB 会新插入一个 document；如果有匹配的 document，MongoDB 会修改或替换这些 document。

# Delete 操作

MongoDB 提供以下操作来删除 collection 中的 document

img

删除操作的特性：

  • MongoDB 中的所有写操作都是单个文档级别的原子操作。

# 二、批量写操作

MongoDB 通过 db.collection.bulkWrite() (opens new window) 方法来支持批量写操作（包括批量插入、更新、删除）。

此外，db.collection.insertMany() (opens new window) 方法支持批量插入操作。

# 有序和无序的操作

批量写操作可以有序或无序。

  • 对于有序列表，MongoDB 串行执行操作。如果在写操作的处理过程中发生错误，MongoDB 将不处理列表中剩余的写操作。
  • 对于无序列表，MongoDB 可以并行执行操作，但是不能保证此行为。如果在写操作的处理过程中发生错误，MongoDB 将继续处理列表中剩余的写操作。

在分片集合上执行操作的有序列表通常比执行无序列表要慢，因为对于有序列表，每个操作必须等待上一个操作完成。

默认情况下，bulkWrite() (opens new window) 执行有序操作。要指定无序写操作，请在选项文档中设置 ordered : false。

# bulkWrite() 方法

bulkWrite() (opens new window) 支持以下写操作：

【示例】批量写操作示例

try {
+  db.characters.bulkWrite([
+    {
+      insertOne: {
+        document: {
+          _id: 4,
+          char: 'Dithras',
+          class: 'barbarian',
+          lvl: 4
+        }
+      }
+    },
+    {
+      insertOne: {
+        document: {
+          _id: 5,
+          char: 'Taeln',
+          class: 'fighter',
+          lvl: 3
+        }
+      }
+    },
+    {
+      updateOne: {
+        filter: { char: 'Eldon' },
+        update: { $set: { status: 'Critical Injury' } }
+      }
+    },
+    { deleteOne: { filter: { char: 'Brisbane' } } },
+    {
+      replaceOne: {
+        filter: { char: 'Meldane' },
+        replacement: { char: 'Tanys', class: 'oracle', lvl: 4 }
+      }
+    }
+  ])
+} catch (e) {
+  print(e)
+}
+

# 批量写操作策略

大量的插入操作（包括初始数据插入或常规数据导入）可能会影响分片集群的性能。对于批量插入，请考虑以下策略：

# 预拆分 collection

如果分片集合为空，则该集合只有一个初始 chunk (opens new window)，该 chunk (opens new window) 位于单个分片上。然后，MongoDB 必须花一些时间来接收数据，创建拆分并将拆分的块分发到可用的分片。为了避免这种性能成本，您可以按照拆分群集中的拆分块中的说明预拆分 collection。

# 无序写操作

要提高对分片集群的写入性能，请使用 bulkWrite() (opens new window)，并将可选参数顺序设置为 false。mongos (opens new window) 可以尝试同时将写入操作发送到多个分片。对于空集合，首先按照分片群集中的分割 chunk (opens new window) 中的说明预拆分 collection。

# 避免单调节流

如果在一次插入操作中，分片 key 单调递增，那么所有的插入数据都会存入 collection 的最后一个 chunk，也就是存入一个分片中。因此，集群的插入容量将永远不会超过该单个分片的插入容量。

如果插入量大于单个分片可以处理的插入量，并且无法避免单调递增的分片键，那么请考虑对应用程序进行以下修改：

  • 反转分片密钥的二进制位。这样可以保留信息，并避免将插入顺序与值序列的增加关联起来。
  • 交换第一个和最后一个 16 位字以“随机”插入。

# SQL 和 MongoDB 对比

# 术语和概念

SQL 术语和概念 MongoDB 术语和概念
database database (opens new window)
table collection (opens new window)
row document (opens new window) 或 BSON (opens new window)
column field (opens new window)
index index (opens new window)
table joins $lookup (opens new window)、嵌入式文档
primary key primary key (opens new window)
MongoDB 中自动设置主键为 _id (opens new window) 字段
aggregation (e.g. group by) aggregation pipeline
参考 SQL to Aggregation Mapping Chart (opens new window).
SELECT INTO NEW_TABLE $out (opens new window)
参考 SQL to Aggregation Mapping Chart (opens new window)
MERGE INTO TABLE $merge (opens new window) (MongoDB 4.2 开始支持)
参考 SQL to Aggregation Mapping Chart (opens new window).
UNION ALL $unionWith (opens new window) (MongoDB 4.4 开始支持)
transactions transactions (opens new window)

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#文档数据库#MongoDB
上次更新: 2023/06/29, 22:27:04
MongoDB 应用指南
MongoDB 的聚合操作

+ ← + MongoDB 的聚合操作→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/8262aa/index.html b/pages/8262aa/index.html new file mode 100644 index 00000000..830b43a2 --- /dev/null +++ b/pages/8262aa/index.html @@ -0,0 +1,74 @@ + + + + + + MySQL 工作流 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-07-16
目录

MySQL 工作流

# MySQL 工作流

# 基础架构

大体来说，MySQL 可以分为 Server 层和存储引擎层两部分。

Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。

img

# 查询过程

SQL 语句在 MySQL 中是如何执行的？

MySQL 整个查询执行过程，总的来说分为 6 个步骤，分别对应 6 个组件：

  1. 连接器：客户端和 MySQL 服务器建立连接；连接器负责跟客户端建立连接、获取权限、维持和管理连接。
  2. MySQL 服务器首先检查查询缓存，如果命中缓存，则立刻返回结果。否则进入下一阶段。
  3. MySQL 服务器进行 SQL 分析：语法分析、词法分析。
  4. MySQL 服务器用优化器生成对应的执行计划。
  5. MySQL 服务器根据执行计划，调用存储引擎的 API 来执行查询。
  6. MySQL 服务器将结果返回给客户端，同时缓存查询结果。

# （一）连接器

使用 MySQL 第一步自然是要连接数据库。连接器负责跟客户端建立连接、获取权限、维持和管理连接。

MySQL 客户端/服务端通信是半双工模式：即任一时刻，要么是服务端向客户端发送数据，要么是客户端向服务器发送数据。客户端用一个单独的数据包将查询请求发送给服务器，所以当查询语句很长的时候，需要设置max_allowed_packet参数。但是需要注意的是，如果查询实在是太大，服务端会拒绝接收更多数据并抛出异常。

MySQL 客户端连接命令：mysql -h<主机> -P<端口> -u<用户名> -p<密码>。如果没有显式指定密码，会要求输入密码才能访问。

连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 show processlist 命令中看到它。客户端如果太长时间没动静，连接器就会自动将它断开。客户端连接维持时间是由参数 wait_timeout 控制的，默认值是 8 小时。如果在连接被断开之后，客户端再次发送请求的话，就会收到一个错误提醒： Lost connection to MySQL server during query。这时候如果你要继续，就需要重连，然后再执行请求了。

建立连接的过程通常是比较复杂的，建议在使用中要尽量减少建立连接的动作，也就是尽量使用长连接。为了在程序中提高数据库连接的服用了，一般会使用数据库连接池来维护管理。

但是全部使用长连接后，你可能会发现，有些时候 MySQL 占用内存涨得特别快，这是因为 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的。这些资源会在连接断开的时候才释放。所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是 MySQL 异常重启了。

怎么解决这个问题呢？你可以考虑以下两种方案。

  • 定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。
  • 如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。

# （二）查询缓存

不建议使用数据库缓存，因为往往弊大于利。

解析一个查询语句前，如果查询缓存是打开的，那么 MySQL 会检查这个查询语句是否命中查询缓存中的数据。如果当前查询恰好命中查询缓存，在检查一次用户权限后直接返回缓存中的结果。这种情况下，查询不会被解析，也不会生成执行计划，更不会执行。

MySQL 将缓存存放在一个引用表（不要理解成table，可以认为是类似于HashMap的数据结构），通过一个哈希值索引，这个哈希值通过查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息计算得来。所以两个查询在任何字符上的不同（例如：空格、注释），都会导致缓存不会命中。

如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql 库中的系统表，其查询结果都不会被缓存。比如函数NOW()或者CURRENT_DATE()会因为不同的查询时间，返回不同的查询结果，再比如包含CURRENT_USER或者CONNECION_ID()的查询语句会因为不同的用户而返回不同的结果，将这样的查询结果缓存起来没有任何的意义。

不建议使用数据库缓存，因为往往弊大于利。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。除非你的业务就是有一张静态表，很长时间才会更新一次。比如，一个系统配置表，那这张表上的查询才适合使用查询缓存。

好在 MySQL 也提供了这种“按需使用”的方式。你可以将参数 query_cache_type 设置成 DEMAND，这样对于默认的 SQL 语句都不使用查询缓存。而对于你确定要使用查询缓存的语句，可以用 SQL_CACHE 显式指定，像下面这个语句一样：

select SQL_CACHE * from T where ID=10;
+

注意：MySQL 8.0 版本直接将查询缓存的整块功能删掉了。

# （三）语法分析

如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL 需要知道你要做什么，因此需要对 SQL 语句做解析。MySQL 通过关键字对 SQL 语句进行解析，并生成一颗对应的语法解析树。这个过程中，分析器主要通过语法规则来验证和解析。比如 SQL 中是否使用了错误的关键字或者关键字的顺序是否正确等等。预处理则会根据 MySQL 规则进一步检查解析树是否合法。比如检查要查询的数据表和数据列是否存在等等。

  • 分析器先会先做“词法分析”。你输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么，代表什么。MySQL 从你输入的"select"这个关键字识别出来，这是一个查询语句。它也要把字符串“T”识别成“表名 T”，把字符串“ID”识别成“列 ID”。
  • 接下来，要做“语法分析”。根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。如果你的语句不对，就会收到“You have an error in your SQL syntax”的错误提醒，比如下面这个语句 select 少打了开头的字母“s”。

# （四）查询优化

经过了分析器，MySQL 就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。

经过前面的步骤生成的语法树被认为是合法的了，并且由优化器将其转化成执行计划。多数情况下，一条查询可以有很多种执行方式，最后都返回相应的结果。优化器的作用就是找到这其中最好的执行计划。

MySQL 使用基于成本的优化器，它尝试预测一个查询使用某种执行计划时的成本，并选择其中成本最小的一个。在 MySQL 可以通过查询当前会话的 last_query_cost 的值来得到其计算当前查询的成本。

mysql> select * from t_message limit 10;
+...省略结果集
+
+mysql> show status like 'last_query_cost';
++-----------------+-------------+
+| Variable_name   | Value       |
++-----------------+-------------+
+| Last_query_cost | 6391.799000 |
++-----------------+-------------+
+

示例中的结果表示优化器认为大概需要做 6391 个数据页的随机查找才能完成上面的查询。这个结果是根据一些列的统计信息计算得来的，这些统计信息包括：每张表或者索引的页面个数、索引的基数、索引和数据行的长度、索引的分布情况等等。

有非常多的原因会导致 MySQL 选择错误的执行计划，比如统计信息不准确、不会考虑不受其控制的操作成本（用户自定义函数、存储过程）、MySQL 认为的最优跟我们想的不一样（我们希望执行时间尽可能短，但 MySQL 值选择它认为成本小的，但成本小并不意味着执行时间短）等等。

MySQL 的查询优化器是一个非常复杂的部件，它使用了非常多的优化策略来生成一个最优的执行计划：

  • 重新定义表的关联顺序（多张表关联查询时，并不一定按照 SQL 中指定的顺序进行，但有一些技巧可以指定关联顺序）
  • 优化MIN()和MAX()函数（找某列的最小值，如果该列有索引，只需要查找 B+Tree 索引最左端，反之则可以找到最大值，具体原理见下文）
  • 提前终止查询（比如：使用 Limit 时，查找到满足数量的结果集后会立即终止查询）
  • 优化排序（在老版本 MySQL 会使用两次传输排序，即先读取行指针和需要排序的字段在内存中对其排序，然后再根据排序结果去读取数据行，而新版本采用的是单次传输排序，也就是一次读取所有的数据行，然后根据给定的列排序。对于 I/O 密集型应用，效率会高很多）

随着 MySQL 的不断发展，优化器使用的优化策略也在不断的进化，这里仅仅介绍几个非常常用且容易理解的优化策略，其他的优化策略，大家自行查阅吧。

# （五）查询执行引擎

在完成解析和优化阶段以后，MySQL 会生成对应的执行计划，查询执行引擎根据执行计划给出的指令逐步执行得出结果。整个执行过程的大部分操作均是通过调用存储引擎实现的接口来完成，这些接口被称为handler API。查询过程中的每一张表由一个handler实例表示。实际上，MySQL 在查询优化阶段就为每一张表创建了一个handler实例，优化器可以根据这些实例的接口来获取表的相关信息，包括表的所有列名、索引统计信息等。存储引擎接口提供了非常丰富的功能，但其底层仅有几十个接口，这些接口像搭积木一样完成了一次查询的大部分操作。

# （六）返回结果

查询过程的最后一个阶段就是将结果返回给客户端。即使查询不到数据，MySQL 仍然会返回这个查询的相关信息，比如该查询影响到的行数以及执行时间等等。

如果查询缓存被打开且这个查询可以被缓存，MySQL 也会将结果存放到缓存中。

结果集返回客户端是一个增量且逐步返回的过程。有可能 MySQL 在生成第一条结果时，就开始向客户端逐步返回结果集了。这样服务端就无须存储太多结果而消耗过多内存，也可以让客户端第一时间获得返回结果。需要注意的是，结果集中的每一行都会以一个满足 ① 中所描述的通信协议的数据包发送，再通过 TCP 协议进行传输，在传输过程中，可能对 MySQL 的数据包进行缓存然后批量发送。

# 更新过程

MySQL 更新过程和 MySQL 查询过程类似，也会将流程走一遍。不一样的是：更新流程还涉及两个重要的日志模块，：redo log（重做日志）和 binlog（归档日志）。

# redo log

redo log 是 InnoDB 引擎特有的日志。redo log 即重做日志。redo log 是物理日志，记录的是“在某个数据页上做了什么修改”。

redo log 是基于 WAL 技术。WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log 里，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。

InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写。

img

有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。

# bin log

bin log 即归档日志。binlog 是逻辑日志，记录的是这个语句的原始逻辑。

binlog 是可以追加写入的，即写到一定大小后会切换到下一个，并不会覆盖以前的日志。

binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。

sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。

# redo log vs. bin log

这两种日志有以下三点不同。

  • redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
  • redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
  • redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

有了对这两个日志的概念性理解，我们再来看执行器和 InnoDB 引擎在执行这个简单的 update 语句时的内部流程。

  1. 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
  2. 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
  3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
  4. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
  5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

这里我给出这个 update 语句的执行流程图，图中浅色框表示是在 InnoDB 内部执行的，深色框表示是在执行器中执行的。

img

# 两阶段提交

redo log 的写入拆成了两个步骤：prepare 和 commit，这就是"两阶段提交"。为什么日志需要“两阶段提交”。

由于 redo log 和 binlog 是两个独立的逻辑，如果不用两阶段提交，要么就是先写完 redo log 再写 binlog，或者采用反过来的顺序。我们看看这两种方式会有什么问题。

  • 先写 redo log 后写 binlog。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于我们前面说过的，redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。 +但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。 +然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。
  • 先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1”这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同。

可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#Mysql
上次更新: 2023/06/29, 22:27:04
Mysql 应用指南
Mysql 事务

+ ← + Mysql 事务→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/83bd15/index.html b/pages/83bd15/index.html new file mode 100644 index 00000000..f293abe8 --- /dev/null +++ b/pages/83bd15/index.html @@ -0,0 +1,1031 @@ + + + + + + Elasticsearch 查询 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-01-18
目录

Elasticsearch 查询

# Elasticsearch 查询

Elasticsearch 查询语句采用基于 RESTful 风格的接口封装成 JSON 格式的对象，称之为 Query DSL。Elasticsearch 查询分类大致分为全文查询、词项查询、复合查询、嵌套查询、位置查询、特殊查询。Elasticsearch 查询从机制分为两种，一种是根据用户输入的查询词，通过排序模型计算文档与查询词之间的相关度，并根据评分高低排序返回；另一种是过滤机制，只根据过滤条件对文档进行过滤，不计算评分，速度相对较快。

# 全文查询

ES 全文查询主要用于在全文字段上，主要考虑查询词与文档的相关性（Relevance）。

# intervals query

intervals query (opens new window) 根据匹配词的顺序和近似度返回文档。

intervals query 使用匹配规则，这些规则应用于指定字段中的 term。

示例：下面示例搜索 query 字段，搜索值是 my favorite food，没有任何间隙；然后是 my_text 字段搜索匹配 hot water、cold porridge 的 term。

当 my_text 中的值为 my favorite food is cold porridge 时，会匹配成功，但是 when it's cold my favorite food is porridge 则匹配失败

POST _search
+{
+  "query": {
+    "intervals" : {
+      "my_text" : {
+        "all_of" : {
+          "ordered" : true,
+          "intervals" : [
+            {
+              "match" : {
+                "query" : "my favorite food",
+                "max_gaps" : 0,
+                "ordered" : true
+              }
+            },
+            {
+              "any_of" : {
+                "intervals" : [
+                  { "match" : { "query" : "hot water" } },
+                  { "match" : { "query" : "cold porridge" } }
+                ]
+              }
+            }
+          ]
+        }
+      }
+    }
+  }
+}
+

# match query

match query (opens new window) 用于搜索单个字段，首先会针对查询语句进行解析（经过 analyzer），主要是对查询语句进行分词，分词后查询语句的任何一个词项被匹配，文档就会被搜到，默认情况下相当于对分词后词项进行 or 匹配操作。

match query (opens new window) 是执行全文搜索的标准查询，包括模糊匹配选项。

GET kibana_sample_data_ecommerce/_search
+{
+  "query": {
+    "match": {
+      "customer_full_name": {
+        "query": "George Hubbard"
+      }
+    }
+  }
+}
+

等同于 or 匹配操作，如下：

GET kibana_sample_data_ecommerce/_search
+{
+  "query": {
+    "match": {
+      "customer_full_name": {
+        "query": "George Hubbard",
+        "operator": "or"
+      }
+    }
+  }
+}
+

# match query 简写

可以通过组合 <field> 和 query 参数来简化匹配查询语法。

示例：

GET /_search
+{
+  "query": {
+    "match": {
+      "message": "this is a test"
+    }
+  }
+}
+

# match query 如何工作

匹配查询是布尔类型。这意味着会对提供的文本进行分析，分析过程从提供的文本构造一个布尔查询。 operator 参数可以设置为 or 或 and 来控制布尔子句（默认为 or）。可以使用 minimum_should_match (opens new window) 参数设置要匹配的可选 should 子句的最小数量。

GET kibana_sample_data_ecommerce/_search
+{
+  "query": {
+    "match": {
+      "customer_full_name": {
+        "query": "George Hubbard",
+        "operator": "and"
+      }
+    }
+  }
+}
+

可以设置 analyzer 来控制哪个分析器将对文本执行分析过程。它默认为字段显式映射定义或默认搜索分析器。

lenient 参数可以设置为 true 以忽略由数据类型不匹配导致的异常，例如尝试使用文本查询字符串查询数字字段。默认为 false。

# match query 的模糊查询

fuzziness 允许基于被查询字段的类型进行模糊匹配。请参阅 Fuzziness (opens new window) 的配置。

在这种情况下可以设置 prefix_length 和 max_expansions 来控制模糊匹配。如果设置了模糊选项，查询将使用 top_terms_blended_freqs_${max_expansions} 作为其重写方法，fuzzy_rewrite 参数允许控制查询将如何被重写。

默认情况下允许模糊倒转 (ab → ba)，但可以通过将 fuzzy_transpositions 设置为 false 来禁用。

GET /_search
+{
+  "query": {
+    "match": {
+      "message": {
+        "query": "this is a testt",
+        "fuzziness": "AUTO"
+      }
+    }
+  }
+}
+

# zero terms 查询

如果使用的分析器像 stop 过滤器一样删除查询中的所有标记，则默认行为是不匹配任何文档。可以使用 zero_terms_query 选项来改变默认行为，它接受 none（默认）和 all （相当于 match_all 查询）。

GET /_search
+{
+  "query": {
+    "match": {
+      "message": {
+        "query": "to be or not to be",
+        "operator": "and",
+        "zero_terms_query": "all"
+      }
+    }
+  }
+}
+

# match_bool_prefix query

match_bool_prefix query (opens new window) 分析其输入并根据这些词构造一个布尔查询。除了最后一个术语之外的每个术语都用于术语查询。最后一个词用于 prefix query。

示例：

GET /_search
+{
+  "query": {
+    "match_bool_prefix" : {
+      "message" : "quick brown f"
+    }
+  }
+}
+

等价于

GET /_search
+{
+  "query": {
+    "bool" : {
+      "should": [
+        { "term": { "message": "quick" }},
+        { "term": { "message": "brown" }},
+        { "prefix": { "message": "f"}}
+      ]
+    }
+  }
+}
+

match_bool_prefix query 和 match_phrase_prefix query 之间的一个重要区别是：match_phrase_prefix query 将其 term 匹配为短语，但 match_bool_prefix query 可以在任何位置匹配其 term。

上面的示例 match_bool_prefix query 查询可以匹配包含 quick brown fox 的字段，但它也可以快速匹配 brown fox。它还可以匹配包含 quick、brown 和以 f 开头的字段，出现在任何位置。

# match_phrase query

match_phrase query (opens new window) 即短语匹配，首先会把 query 内容分词，分词器可以自定义，同时文档还要满足以下两个条件才会被搜索到：

  1. 分词后所有词项都要出现在该字段中（相当于 and 操作）。
  2. 字段中的词项顺序要一致。

例如，有以下 3 个文档，使用 match_phrase 查询 "How are you"，只有前两个文档会被匹配：

PUT demo/_create/1
+{ "desc": "How are you" }
+
+PUT demo/_create/2
+{ "desc": "How are you, Jack?"}
+
+PUT demo/_create/3
+{ "desc": "are you"}
+
+GET demo/_search
+{
+  "query": {
+    "match_phrase": {
+      "desc": "How are you"
+    }
+  }
+}
+

说明：

一个被认定为和短语 How are you 匹配的文档，必须满足以下这些要求：

  • How、 are 和 you 需要全部出现在域中。
  • are 的位置应该比 How 的位置大 1 。
  • you 的位置应该比 How 的位置大 2 。

# match_phrase_prefix query

match_phrase_prefix query (opens new window) 和 match_phrase query (opens new window) 类似，只不过 match_phrase_prefix query (opens new window) 最后一个 term 会被作为前缀匹配。

GET demo/_search
+{
+  "query": {
+    "match_phrase_prefix": {
+      "desc": "are yo"
+    }
+  }
+}
+

# multi_match query

multi_match query (opens new window) 是 match query 的升级，用于搜索多个字段。

示例：

GET kibana_sample_data_ecommerce/_search
+{
+  "query": {
+    "multi_match": {
+      "query": 34.98,
+      "fields": [
+        "taxful_total_price",
+        "taxless_total_price"
+      ]
+    }
+  }
+}
+

multi_match query 的搜索字段可以使用通配符指定，示例如下：

GET kibana_sample_data_ecommerce/_search
+{
+  "query": {
+    "multi_match": {
+      "query": 34.98,
+      "fields": [
+        "taxful_*",
+        "taxless_total_price"
+      ]
+    }
+  }
+}
+

同时，也可以用指数符指定搜索字段的权重。

示例：指定 taxful_total_price 字段的权重是 taxless_total_price 字段的 3 倍，命令如下：

GET kibana_sample_data_ecommerce/_search
+{
+  "query": {
+    "multi_match": {
+      "query": 34.98,
+      "fields": [
+        "taxful_total_price^3",
+        "taxless_total_price"
+      ]
+    }
+  }
+}
+

# combined_fields query

combined_fields query (opens new window) 支持搜索多个文本字段，就好像它们的内容已被索引到一个组合字段中一样。该查询会生成以 term 为中心的输入字符串视图：首先它将查询字符串解析为独立的 term，然后在所有字段中查找每个 term。当匹配结果可能跨越多个文本字段时，此查询特别有用，例如文章的标题、摘要和正文：

GET /_search
+{
+  "query": {
+    "combined_fields" : {
+      "query":      "database systems",
+      "fields":     [ "title", "abstract", "body"],
+      "operator":   "and"
+    }
+  }
+}
+

# 字段前缀权重

字段前缀权重根据组合字段模型进行计算。例如，如果 title 字段的权重为 2，则匹配度打分时会将 title 中的每个 term 形成的组合字段，按出现两次进行打分。

# common_terms query

7.3.0 废弃

common_terms query (opens new window) 是一种在不牺牲性能的情况下替代停用词提高搜索准确率和召回率的方案。

查询中的每个词项都有一定的代价，以搜索“The brown fox”为例，query 会被解析成三个词项“the”“brown”和“fox”，每个词项都会到索引中执行一次查询。很显然包含“the”的文档非常多，相比其他词项，“the”的重要性会低很多。传统的解决方案是把“the”当作停用词处理，去除停用词之后可以减少索引大小，同时在搜索时减少对停用词的收缩。

虽然停用词对文档评分影响不大，但是当停用词仍然有重要意义的时候，去除停用词就不是完美的解决方案了。如果去除停用词，就无法区分“happy”和“not happy”, “The”“To be or not to be”就不会在索引中存在，搜索的准确率和召回率就会降低。

common_terms query 提供了一种解决方案，它把 query 分词后的词项分成重要词项（低频词项）和不重要的词项（高频词，也就是之前的停用词）。在搜索的时候，首先搜索和重要词项匹配的文档，这些文档是词项出现较少并且词项对其评分影响较大的文档。然后执行第二次查询，搜索对评分影响较小的高频词项，但是不计算所有文档的评分，而是只计算第一次查询已经匹配的文档得分。如果一个查询中只包含高频词，那么会通过 and 连接符执行一个单独的查询，换言之，会搜索所有的词项。

词项是高频词还是低频词是通过 cutoff frequency 来设置阀值的，取值可以是绝对频率（频率大于 1）或者相对频率（0 ～ 1）。common_terms query 最有趣之处在于它能自适应特定领域的停用词，例如，在视频托管网站上，诸如“clip”或“video”之类的高频词项将自动表现为停用词，无须保留手动列表。

例如，文档频率高于 0.1% 的词项将会被当作高频词项，词频之间可以用 low_freq_operator、high_freq_operator 参数连接。设置低频词操作符为“and”使所有的低频词都是必须搜索的，示例代码如下：

GET books/_search
+{
+	"query": {
+		"common": {
+			"body": {
+				"query": "nelly the elephant as a cartoon",
+				"cutoff_frequency": 0.001,
+				"low_freq_operator": "and"
+			}
+		}
+	}
+}
+

上述操作等价于：

GET books/_search
+{
+	"query": {
+		"bool": {
+			"must": [
+			  { "term": { "body": "nelly" } },
+			  { "term": { "body": "elephant" } },
+			  { "term": { "body": "cartoon" } }
+			],
+			"should": [
+			  { "term": { "body": "the" } },
+			  { "term": { "body": "as" } },
+			  { "term": { "body": "a" } }
+			]
+		}
+	}
+}
+

# query_string query

query_string query (opens new window) 是与 Lucene 查询语句的语法结合非常紧密的一种查询，允许在一个查询语句中使用多个特殊条件关键字（如：AND | OR | NOT）对多个字段进行查询，建议熟悉 Lucene 查询语法的用户去使用。

用户可以使用 query_string query 来创建包含通配符、跨多个字段的搜索等复杂搜索。虽然通用，但查询是严格的，如果查询字符串包含任何无效语法，则会返回错误。

示例：

GET /_search
+{
+  "query": {
+    "query_string": {
+      "query": "(new york city) OR (big apple)",
+      "default_field": "content"
+    }
+  }
+}
+

# simple_query_string query

simple_query_string query (opens new window) 是一种适合直接暴露给用户，并且具有非常完善的查询语法的查询语句，接受 Lucene 查询语法，解析过程中发生错误不会抛出异常。

虽然语法比 query_string query (opens new window) 更严格，但 simple_query_string query (opens new window) 不会返回无效语法的错误。相反，它会忽略查询字符串的任何无效部分。

示例：

GET /_search
+{
+  "query": {
+    "simple_query_string" : {
+        "query": "\"fried eggs\" +(eggplant | potato) -frittata",
+        "fields": ["title^5", "body"],
+        "default_operator": "and"
+    }
+  }
+}
+

# simple_query_string 语义

  • +：等价于 AND 操作
  • |：等价于 OR 操作
  • -：相当于 NOT 操作
  • "：包装一些标记以表示用于搜索的短语
  • *：词尾表示前缀查询
  • ( and )：表示优先级
  • ~N：词尾表示表示编辑距离（模糊性）
  • ~N：在一个短语之后表示溢出量

注意：要使用上面的字符，请使用反斜杠 / 对其进行转义。

# 全文查询完整示例

#设置 position_increment_gap
+DELETE groups
+PUT groups
+{
+  "mappings": {
+    "properties": {
+      "names":{
+        "type": "text",
+        "position_increment_gap": 0
+      }
+    }
+  }
+}
+
+GET groups/_mapping
+
+POST groups/_doc
+{
+  "names": [ "John Water", "Water Smith"]
+}
+
+POST groups/_search
+{
+  "query": {
+    "match_phrase": {
+      "names": {
+        "query": "Water Water",
+        "slop": 100
+      }
+    }
+  }
+}
+
+POST groups/_search
+{
+  "query": {
+    "match_phrase": {
+      "names": "Water Smith"
+    }
+  }
+}
+
+DELETE groups
+

# 词项查询

Term（词项）是表达语意的最小单位。搜索和利用统计语言模型进行自然语言处理都需要处理 Term。

全文查询在执行查询之前会分析查询字符串。

与全文查询不同，词项查询不会分词，而是将输入作为一个整体，在倒排索引中查找准确的词项。并且使用相关度计算公式为每个包含该词项的文档进行相关度计算。一言以概之：词项查询是对词项进行精确匹配。词项查询通常用于结构化数据，如数字、日期和枚举类型。

词项查询有以下类型：

# exists query

exists query (opens new window) 会返回字段中至少有一个非空值的文档。

由于多种原因，文档字段可能不存在索引值：

  • JSON 中的字段为 null 或 []
  • 该字段在 mapping 中配置了 "index" : false
  • 字段值的长度超过了 mapping 中的 ignore_above 设置
  • 字段值格式错误，并且在 mapping 中定义了 ignore_malformed

示例：

GET kibana_sample_data_ecommerce/_search
+{
+  "query": {
+    "exists": {
+      "field": "email"
+    }
+  }
+}
+

以下文档会匹配上面的查询：

  • { "user" : "jane" } 有 user 字段，且不为空。
  • { "user" : "" } 有 user 字段，值为空字符串。
  • { "user" : "-" } 有 user 字段，值不为空。
  • { "user" : [ "jane" ] } 有 user 字段，值不为空。
  • { "user" : [ "jane", null ] } 有 user 字段，至少一个值不为空即可。

下面的文档都不会被匹配：

  • { "user" : null } 虽然有 user 字段，但是值为空。
  • { "user" : [] } 虽然有 user 字段，但是值为空。
  • { "user" : [null] } 虽然有 user 字段，但是值为空。
  • { "foo" : "bar" } 没有 user 字段。

# fuzzy query

fuzzy query（模糊查询） (opens new window)返回包含与搜索词相似的词的文档。ES 使用 Levenshtein edit distance（Levenshtein 编辑距离） (opens new window)测量相似度或模糊度。

编辑距离是将一个术语转换为另一个术语所需的单个字符更改的数量。这些变化可能包括：

  • 改变一个字符：（box -> fox）
  • 删除一个字符：（black -> lack）
  • 插入一个字符：（sic -> sick）
  • 反转两个相邻字符：（act → cat）

为了找到相似的词条，fuzzy query 会在指定的编辑距离内创建搜索词条的所有可能变体或扩展集。然后返回完全匹配任意扩展的文档。

GET books/_search
+{
+  "query": {
+    "fuzzy": {
+      "user.id": {
+        "value": "ki",
+        "fuzziness": "AUTO",
+        "max_expansions": 50,
+        "prefix_length": 0,
+        "transpositions": true,
+        "rewrite": "constant_score"
+      }
+    }
+  }
+}
+

注意：如果配置了 search.allow_expensive_queries (opens new window) ，则 fuzzy query 不能执行。

# ids query

ids query (opens new window) 根据 ID 返回文档。 此查询使用存储在 _id 字段中的文档 ID。

GET /_search
+{
+  "query": {
+    "ids" : {
+      "values" : ["1", "4", "100"]
+    }
+  }
+}
+

# prefix query

prefix query (opens new window) 用于查询某个字段中包含指定前缀的文档。

比如查询 user.id 中含有以 ki 为前缀的关键词的文档，那么含有 kind、kid 等所有以 ki 开头关键词的文档都会被匹配。

GET /_search
+{
+  "query": {
+    "prefix": {
+      "user.id": {
+        "value": "ki"
+      }
+    }
+  }
+}
+

# range query

range query (opens new window) 即范围查询，用于匹配在某一范围内的数值型、日期类型或者字符串型字段的文档。比如搜索哪些书籍的价格在 50 到 100 之间、哪些书籍的出版时间在 2015 年到 2019 年之间。使用 range 查询只能查询一个字段，不能作用在多个字段上。

range 查询支持的参数有以下几种：

  • gt：大于

  • gte：大于等于

  • lt：小于

  • lte：小于等于

  • format：如果字段是 Date 类型，可以设置日期格式化

  • time_zone：时区

  • relation：指示范围查询如何匹配范围字段的值。

    • INTERSECTS (Default)：匹配与查询字段值范围相交的文档。
    • CONTAINS：匹配完全包含查询字段值的文档。
    • WITHIN：匹配具有完全在查询范围内的范围字段值的文档。

示例：数值范围查询

GET kibana_sample_data_ecommerce/_search
+{
+  "query": {
+    "range": {
+      "taxful_total_price": {
+        "gt": 10,
+        "lte": 50
+      }
+    }
+  }
+}
+

示例：日期范围查询

GET kibana_sample_data_ecommerce/_search
+{
+  "query": {
+    "range": {
+      "order_date": {
+        "time_zone": "+00:00",
+        "gte": "2018-01-01T00:00:00",
+        "lte": "now"
+      }
+    }
+  }
+}
+

# regexp query

regexp query (opens new window) 返回与正则表达式相匹配的 term 所属的文档。

正则表达式 (opens new window)是一种使用占位符字符匹配数据模式的方法，称为运算符。

示例：以下搜索返回 user.id 字段包含任何以 k 开头并以 y 结尾的文档。 .* 运算符匹配任何长度的任何字符，包括无字符。匹配项可以包括 ky、kay 和 kimchy。

GET /_search
+{
+  "query": {
+    "regexp": {
+      "user.id": {
+        "value": "k.*y",
+        "flags": "ALL",
+        "case_insensitive": true,
+        "max_determinized_states": 10000,
+        "rewrite": "constant_score"
+      }
+    }
+  }
+}
+

注意：如果配置了search.allow_expensive_queries (opens new window) ，则 regexp query (opens new window) 会被禁用。

# term query

term query (opens new window) 用来查找指定字段中包含给定单词的文档，term 查询不被解析，只有查询词和文档中的词精确匹配才会被搜索到，应用场景为查询人名、地名等需要精准匹配的需求。

示例：

# 1. 创建一个索引
+DELETE my-index-000001
+PUT my-index-000001
+{
+  "mappings": {
+    "properties": {
+      "full_text": { "type": "text" }
+    }
+  }
+}
+
+# 2. 使用 "Quick Brown Foxes!" 关键字查 "full_text" 字段
+PUT my-index-000001/_doc/1
+{
+  "full_text": "Quick Brown Foxes!"
+}
+
+# 3. 使用 term 查询
+GET my-index-000001/_search?pretty
+{
+  "query": {
+    "term": {
+      "full_text": "Quick Brown Foxes!"
+    }
+  }
+}
+# 因为 full_text 字段不再包含确切的 Term —— "Quick Brown Foxes!"，所以 term query 搜索不到任何结果
+
+# 4. 使用 match 查询
+GET my-index-000001/_search?pretty
+{
+  "query": {
+    "match": {
+      "full_text": "Quick Brown Foxes!"
+    }
+  }
+}
+
+DELETE my-index-000001
+

⚠️ 注意：应避免 term 查询对 text 字段使用查询。

默认情况下，Elasticsearch 针对 text 字段的值进行解析分词，这会使查找 text 字段值的精确匹配变得困难。

要搜索 text 字段值，需改用 match 查询。

# terms query

terms query (opens new window) 与 term query (opens new window) 相同，但可以搜索多个值。

terms query 查询参数：

  • index：索引名
  • id：文档 ID
  • path：要从中获取字段值的字段的名称，即搜索关键字
  • routing（选填）：要从中获取 term 值的文档的自定义路由值。如果在索引文档时提供了自定义路由值，则此参数是必需的。

示例：

# 1. 创建一个索引
+DELETE my-index-000001
+PUT my-index-000001
+{
+  "mappings": {
+    "properties": {
+      "color": { "type": "keyword" }
+    }
+  }
+}
+
+# 2. 写入一个文档
+PUT my-index-000001/_doc/1
+{
+  "color": [
+    "blue",
+    "green"
+  ]
+}
+
+# 3. 写入另一个文档
+PUT my-index-000001/_doc/2
+{
+  "color": "blue"
+}
+
+# 3. 使用 terms query
+GET my-index-000001/_search?pretty
+{
+  "query": {
+    "terms": {
+      "color": {
+        "index": "my-index-000001",
+        "id": "2",
+        "path": "color"
+      }
+    }
+  }
+}
+
+DELETE my-index-000001
+

# type query

7.0.0 后废弃

type query (opens new window) 用于查询具有指定类型的文档。

示例：

GET /_search
+{
+  "query": {
+    "type": {
+      "value": "_doc"
+    }
+  }
+}
+

# wildcard query

wildcard query (opens new window) 即通配符查询，返回与通配符模式匹配的文档。

? 用来匹配一个任意字符，* 用来匹配零个或者多个字符。

示例：以下搜索返回 user.id 字段包含以 ki 开头并以 y 结尾的术语的文档。这些匹配项可以包括 kiy、kity 或 kimchy。

GET /_search
+{
+  "query": {
+    "wildcard": {
+      "user.id": {
+        "value": "ki*y",
+        "boost": 1.0,
+        "rewrite": "constant_score"
+      }
+    }
+  }
+}
+

注意：如果配置了search.allow_expensive_queries (opens new window) ，则wildcard query (opens new window) 会被禁用。

# 词项查询完整示例

DELETE products
+PUT products
+{
+  "settings": {
+    "number_of_shards": 1
+  }
+}
+
+POST /products/_bulk
+{ "index": { "_id": 1 }}
+{ "productID" : "XHDK-A-1293-#fJ3","desc":"iPhone" }
+{ "index": { "_id": 2 }}
+{ "productID" : "KDKE-B-9947-#kL5","desc":"iPad" }
+{ "index": { "_id": 3 }}
+{ "productID" : "JODL-X-1937-#pV7","desc":"MBP" }
+
+GET /products
+
+POST /products/_search
+{
+  "query": {
+    "term": {
+      "desc": {
+        //"value": "iPhone"
+        "value":"iphone"
+      }
+    }
+  }
+}
+
+POST /products/_search
+{
+  "query": {
+    "term": {
+      "desc.keyword": {
+        //"value": "iPhone"
+        //"value":"iphone"
+      }
+    }
+  }
+}
+
+POST /products/_search
+{
+  "query": {
+    "term": {
+      "productID": {
+        "value": "XHDK-A-1293-#fJ3"
+      }
+    }
+  }
+}
+
+POST /products/_search
+{
+  //"explain": true,
+  "query": {
+    "term": {
+      "productID.keyword": {
+        "value": "XHDK-A-1293-#fJ3"
+      }
+    }
+  }
+}
+
+POST /products/_search
+{
+  "explain": true,
+  "query": {
+    "constant_score": {
+      "filter": {
+        "term": {
+          "productID.keyword": "XHDK-A-1293-#fJ3"
+        }
+      }
+
+    }
+  }
+}
+

# 复合查询

复合查询就是把一些简单查询组合在一起实现更复杂的查询需求，除此之外，复合查询还可以控制另外一个查询的行为。

# bool query

bool 查询可以把任意多个简单查询组合在一起，使用 must、should、must_not、filter 选项来表示简单查询之间的逻辑，每个选项都可以出现 0 次到多次，它们的含义如下：

  • must 文档必须匹配 must 选项下的查询条件，相当于逻辑运算的 AND，且参与文档相关度的评分。
  • should 文档可以匹配 should 选项下的查询条件也可以不匹配，相当于逻辑运算的 OR，且参与文档相关度的评分。
  • must_not 与 must 相反，匹配该选项下的查询条件的文档不会被返回；需要注意的是，must_not 语句不会影响评分，它的作用只是将不相关的文档排除。
  • filter 和 must 一样，匹配 filter 选项下的查询条件的文档才会被返回，但是 filter 不评分，只起到过滤功能，与 must_not 相反。

假设要查询 title 中包含关键词 java，并且 price 不能高于 70，description 可以包含也可以不包含虚拟机的书籍，构造 bool 查询语句如下：

GET books/_search
+{
+  "query": {
+    "bool": {
+      "filter": {
+        "term": {
+          "status": 1
+        }
+      },
+      "must_not": {
+        "range": {
+          "price": {
+            "gte": 70
+          }
+        }
+      },
+      "must": {
+        "match": {
+          "title": "java"
+        }
+      },
+      "should": [
+        {
+          "match": {
+            "description": "虚拟机"
+          }
+        }
+      ],
+      "minimum_should_match": 1
+    }
+  }
+}
+

有关布尔查询更详细的信息参考 bool query（组合查询）详解 (opens new window)。

# boosting query

boosting 查询用于需要对两个查询的评分进行调整的场景，boosting 查询会把两个查询封装在一起并降低其中一个查询的评分。

boosting 查询包括 positive、negative 和 negative_boost 三个部分，positive 中的查询评分保持不变，negative 中的查询会降低文档评分，negative_boost 指明 negative 中降低的权值。如果我们想对 2015 年之前出版的书降低评分，可以构造一个 boosting 查询，查询语句如下：

GET books/_search
+{
+	"query": {
+		"boosting": {
+			"positive": {
+				"match": {
+					"title": "python"
+				}
+			},
+			"negative": {
+				"range": {
+					"publish_time": {
+						"lte": "2015-01-01"
+					}
+				}
+			},
+			"negative_boost": 0.2
+		}
+	}
+}
+

boosting 查询中指定了抑制因子为 0.2，publish_time 的值在 2015-01-01 之后的文档得分不变，publish_time 的值在 2015-01-01 之前的文档得分为原得分的 0.2 倍。

# constant_score query

constantscore query 包装一个 filter query，并返回匹配过滤器查询条件的文档，且它们的相关性评分都等于 _boost 参数值（可以理解为原有的基于 tf-idf 或 bm25 的相关分固定为 1.0，所以最终评分为 1.0 * boost，即等于 boost 参数值）。下面的查询语句会返回 title 字段中含有关键词 elasticsearch 的文档，所有文档的评分都是 1.8：

GET books/_search
+{
+  "query": {
+    "constant_score": {
+      "filter": {
+        "term": {
+          "title": "elasticsearch"
+        }
+      },
+      "boost": 1.8
+    }
+  }
+}
+

# dis_max query

dis_max query 与 bool query 有一定联系也有一定区别，dis_max query 支持多并发查询，可返回与任意查询条件子句匹配的任何文档类型。与 bool 查询可以将所有匹配查询的分数相结合使用的方式不同，dis_max 查询只使用最佳匹配查询条件的分数。请看下面的例子：

GET books/_search
+{
+	"query": {
+		"dis_max": {
+			"tie_breaker": 0.7,
+			"boost": 1.2,
+			"queries": [{
+					"term": {
+						"age": 34
+					}
+				},
+				{
+					"term": {
+						"age": 35
+					}
+				}
+			]
+		}
+	}
+}
+

# function_score query

function_score query 可以修改查询的文档得分，这个查询在有些情况下非常有用，比如通过评分函数计算文档得分代价较高，可以改用过滤器加自定义评分函数的方式来取代传统的评分方式。

使用 function_score query，用户需要定义一个查询和一至多个评分函数，评分函数会对查询到的每个文档分别计算得分。

下面这条查询语句会返回 books 索引中的所有文档，文档的最大得分为 5，每个文档的得分随机生成，权重的计算模式为相乘模式。

GET books/_search
+{
+  "query": {
+    "function_score": {
+      "query": {
+        "match all": {}
+      },
+      "boost": "5",
+      "random_score": {},
+      "boost_mode": "multiply"
+    }
+  }
+}
+

使用脚本自定义评分公式，这里把 price 值的十分之一开方作为每个文档的得分，查询语句如下：

GET books/_search
+{
+  "query": {
+    "function_score": {
+      "query": {
+        "match": {
+          "title": "java"
+        }
+      },
+      "script_score": {
+        "inline": "Math.sqrt(doc['price'].value/10)"
+      }
+    }
+  }
+}
+

关于 function_score 的更多详细内容请查看 Elasticsearch function_score 查询最强详解 (opens new window)。

# indices query

indices query 适用于需要在多个索引之间进行查询的场景，它允许指定一个索引名字列表和内部查询。indices query 中有 query 和 no_match_query 两部分，query 中用于搜索指定索引列表中的文档，no_match_query 中的查询条件用于搜索指定索引列表之外的文档。下面的查询语句实现了搜索索引 books、books2 中 title 字段包含关键字 javascript，其他索引中 title 字段包含 basketball 的文档，查询语句如下：

GET books/_search
+{
+	"query": {
+		"indices": {
+			"indices": ["books", "books2"],
+			"query": {
+				"match": {
+					"title": "javascript"
+				}
+			},
+			"no_match_query": {
+				"term": {
+					"title": "basketball"
+				}
+			}
+		}
+	}
+}
+

# 嵌套查询

在 Elasticsearch 这样的分布式系统中执行全 SQL 风格的连接查询代价昂贵，是不可行的。相应地，为了实现水平规模地扩展，Elasticsearch 提供了以下两种形式的 join：

  • nested query（嵌套查询）

    文档中可能包含嵌套类型的字段，这些字段用来索引一些数组对象，每个对象都可以作为一条独立的文档被查询出来。

  • has_child query（有子查询）和 has_parent query（有父查询）

    父子关系可以存在单个的索引的两个类型的文档之间。has_child 查询将返回其子文档能满足特定查询的父文档，而 has_parent 则返回其父文档能满足特定查询的子文档。

# nested query

文档中可能包含嵌套类型的字段，这些字段用来索引一些数组对象，每个对象都可以作为一条独立的文档被查询出来（用嵌套查询）。

PUT /my_index
+{
+	"mappings": {
+		"type1": {
+			"properties": {
+				"obj1": {
+					"type": "nested"
+				}
+			}
+		}
+	}
+}
+

# has_child query

文档的父子关系创建索引时在映射中声明，这里以员工（employee）和工作城市（branch）为例，它们属于不同的类型，相当于数据库中的两张表，如果想把员工和他们工作的城市关联起来，需要告诉 Elasticsearch 文档之间的父子关系，这里 employee 是 child type，branch 是 parent type，在映射中声明，执行命令：

PUT /company
+{
+	"mappings": {
+		"branch": {},
+		"employee": {
+			"parent": { "type": "branch" }
+		}
+	}
+}
+

使用 bulk api 索引 branch 类型下的文档，命令如下：

POST company/branch/_bulk
+{ "index": { "_id": "london" }}
+{ "name": "London Westminster","city": "London","country": "UK" }
+{ "index": { "_id": "liverpool" }}
+{ "name": "Liverpool Central","city": "Liverpool","country": "UK" }
+{ "index": { "_id": "paris" }}
+{ "name": "Champs Elysees","city": "Paris","country": "France" }
+

添加员工数据：

POST company/employee/_bulk
+{ "index": { "_id": 1,"parent":"london" }}
+{ "name": "Alice Smith","dob": "1970-10-24","hobby": "hiking" }
+{ "index": { "_id": 2,"parent":"london" }}
+{ "name": "Mark Tomas","dob": "1982-05-16","hobby": "diving" }
+{ "index": { "_id": 3,"parent":"liverpool" }}
+{ "name": "Barry Smith","dob": "1979-04-01","hobby": "hiking" }
+{ "index": { "_id": 4,"parent":"paris" }}
+{ "name": "Adrien Grand","dob": "1987-05-11","hobby": "horses" }
+

通过子文档查询父文档要使用 has_child 查询。例如，搜索 1980 年以后出生的员工所在的分支机构，employee 中 1980 年以后出生的有 Mark Thomas 和 Adrien Grand，他们分别在 london 和 paris，执行以下查询命令进行验证：

GET company/branch/_search
+{
+	"query": {
+		"has_child": {
+			"type": "employee",
+			"query": {
+				"range": { "dob": { "gte": "1980-01-01" } }
+			}
+		}
+	}
+}
+

搜索哪些机构中有名为 “Alice Smith” 的员工，因为使用 match 查询，会解析为 “Alice” 和 “Smith”，所以 Alice Smith 和 Barry Smith 所在的机构会被匹配，执行以下查询命令进行验证：

GET company/branch/_search
+{
+	"query": {
+		"has_child": {
+			"type": "employee",
+			"score_mode": "max",
+			"query": {
+				"match": { "name": "Alice Smith" }
+			}
+		}
+	}
+}
+

可以使用 min_children 指定子文档的最小个数。例如，搜索最少含有两个 employee 的机构，查询命令如下：

GET company/branch/_search?pretty
+{
+	"query": {
+		"has_child": {
+			"type": "employee",
+			"min_children": 2,
+			"query": {
+				"match_all": {}
+			}
+		}
+	}
+}
+

# has_parent query

通过父文档查询子文档使用 has_parent 查询。比如，搜索哪些 employee 工作在 UK，查询命令如下：

GET company/employee/_search
+{
+	"query": {
+		"has_parent": {
+			"parent_type": "branch",
+			"query": {
+				"match": { "country": "UK }
+			}
+		}
+	}
+}
+

# 位置查询

Elasticsearch 可以对地理位置点 geo_point 类型和地理位置形状 geo_shape 类型的数据进行搜索。为了学习方便，这里准备一些城市的地理坐标作为测试数据，每一条文档都包含城市名称和地理坐标这两个字段，这里的坐标点取的是各个城市中心的一个位置。首先把下面的内容保存到 geo.json 文件中：

{"index":{ "_index":"geo","_type":"city","_id":"1" }}
+{"name":"北京","location":"39.9088145109,116.3973999023"}
+{"index":{ "_index":"geo","_type":"city","_id": "2" }}
+{"name":"乌鲁木齐","location":"43.8266300000,87.6168800000"}
+{"index":{ "_index":"geo","_type":"city","_id":"3" }}
+{"name":"西安","location":"34.3412700000,108.9398400000"}
+{"index":{ "_index":"geo","_type":"city","_id":"4" }}
+{"name":"郑州","location":"34.7447157466,113.6587142944"}
+{"index":{ "_index":"geo","_type":"city","_id":"5" }}
+{"name":"杭州","location":"30.2294080260,120.1492309570"}
+{"index":{ "_index":"geo","_type":"city","_id":"6" }}
+{"name":"济南","location":"36.6518400000,117.1200900000"}
+

创建一个索引并设置映射：

PUT geo
+{
+	"mappings": {
+		"city": {
+			"properties": {
+				"name": {
+					"type": "keyword"
+				},
+				"location": {
+					"type": "geo_point"
+				}
+			}
+		}
+	}
+}
+

然后执行批量导入命令：

curl -XPOST "http://localhost:9200/_bulk?pretty" --data-binary @geo.json
+

# geo_distance query

geo_distance query 可以查找在一个中心点指定范围内的地理点文档。例如，查找距离天津 200km 以内的城市，搜索结果中会返回北京，命令如下：

GET geo/_search
+{
+	"query": {
+		"bool": {
+			"must": {
+				"match_all": {}
+			},
+			"filter": {
+				"geo_distance": {
+					"distance": "200km",
+					"location": {
+						"lat": 39.0851000000,
+						"lon": 117.1993700000
+					}
+				}
+			}
+		}
+	}
+}
+

按各城市离北京的距离排序：

GET geo/_search
+{
+  "query": {
+    "match_all": {}
+  },
+  "sort": [{
+    "_geo_distance": {
+      "location": "39.9088145109,116.3973999023",
+      "unit": "km",
+      "order": "asc",
+      "distance_type": "plane"
+    }
+  }]
+}
+

其中 location 对应的经纬度字段；unit 为 km 表示将距离以 km 为单位写入到每个返回结果的 sort 键中；distance_type 为 plane 表示使用快速但精度略差的 plane 计算方式。

# geo_bounding_box query

geo_bounding_box query 用于查找落入指定的矩形内的地理坐标。查询中由两个点确定一个矩形，然后在矩形区域内查询匹配的文档。

GET geo/_search
+{
+	"query": {
+		"bool": {
+			"must": {
+				"match_all": {}
+			},
+			"filter": {
+				"geo_bounding_box": {
+					"location": {
+						"top_left": {
+							"lat": 38.4864400000,
+							"lon": 106.2324800000
+						},
+						"bottom_right": {
+							"lat": 28.6820200000,
+							"lon": 115.8579400000
+						}
+					}
+				}
+			}
+		}
+	}
+}
+

# geo_polygon query

geo_polygon query 用于查找在指定多边形内的地理点。例如，呼和浩特、重庆、上海三地组成一个三角形，查询位置在该三角形区域内的城市，命令如下：

GET geo/_search
+{
+	"query": {
+		"bool": {
+			"must": {
+				"match_all": {}
+			}
+		},
+		"filter": {
+			"geo_polygon": {
+				"location": {
+					"points": [{
+						"lat": 40.8414900000,
+						"lon": 111.7519900000
+					}, {
+						"lat": 29.5647100000,
+						"lon": 106.5507300000
+					}, {
+						"lat": 31.2303700000,
+						"lon": 121.4737000000
+					}]
+				}
+			}
+		}
+	}
+}
+

# geo_shape query

geo_shape query 用于查询 geo_shape 类型的地理数据，地理形状之间的关系有相交、包含、不相交三种。创建一个新的索引用于测试，其中 location 字段的类型设为 geo_shape 类型。

PUT geoshape
+{
+	"mappings": {
+		"city": {
+			"properties": {
+				"name": {
+					"type": "keyword"
+				},
+				"location": {
+					"type": "geo_shape"
+				}
+			}
+		}
+	}
+}
+

关于经纬度的顺序这里做一个说明，geo_point 类型的字段纬度在前经度在后，但是对于 geo_shape 类型中的点，是经度在前纬度在后，这一点需要特别注意。

把西安和郑州连成的线写入索引：

POST geoshape/city/1
+{
+	"name": "西安-郑州",
+	"location": {
+		"type": "linestring",
+		"coordinates": [
+			[108.9398400000, 34.3412700000],
+			[113.6587142944, 34.7447157466]
+		]
+	}
+}
+

查询包含在由银川和南昌作为对角线上的点组成的矩形的地理形状，由于西安和郑州组成的直线落在该矩形区域内，因此可以被查询到。命令如下：

GET geoshape/_search
+{
+	"query": {
+		"bool": {
+			"must": {
+				"match_all": {}
+			},
+			"filter": {
+				"geo_shape": {
+					"location": {
+						"shape": {
+							"type": "envelope",
+							"coordinates": [
+								[106.23248, 38.48644],
+								[115.85794, 28.68202]
+							]
+						},
+						"relation": "within"
+					}
+				}
+			}
+		}
+	}
+}
+

# 特殊查询

# more_like_this query

more_like_this query 可以查询和提供文本类似的文档，通常用于近似文本的推荐等场景。查询命令如下：

GET books/_search
+{
+	"query": {
+		"more_like_ this": {
+			"fields": ["title", "description"],
+			"like": "java virtual machine",
+			"min_term_freq": 1,
+			"max_query_terms": 12
+		}
+	}
+}
+

可选的参数及取值说明如下：

  • fields 要匹配的字段，默认是 _all 字段。
  • like 要匹配的文本。
  • min_term_freq 文档中词项的最低频率，默认是 2，低于此频率的文档会被忽略。
  • max_query_terms query 中能包含的最大词项数目，默认为 25。
  • min_doc_freq 最小的文档频率，默认为 5。
  • max_doc_freq 最大文档频率。
  • min_word length 单词的最小长度。
  • max_word length 单词的最大长度。
  • stop_words 停用词列表。
  • analyzer 分词器。
  • minimum_should_match 文档应匹配的最小词项数，默认为 query 分词后词项数的 30%。
  • boost terms 词项的权重。
  • include 是否把输入文档作为结果返回。
  • boost 整个 query 的权重，默认为 1.0。

# script query

Elasticsearch 支持使用脚本进行查询。例如，查询价格大于 180 的文档，命令如下：

GET books/_search
+{
+  "query": {
+    "script": {
+      "script": {
+        "inline": "doc['price'].value > 180",
+        "lang": "painless"
+      }
+    }
+  }
+}
+

# percolate query

一般情况下，我们是先把文档写入到 Elasticsearch 中，通过查询语句对文档进行搜索。percolate query 则是反其道而行之的做法，它会先注册查询条件，根据文档来查询 query。例如，在 my-index 索引中有一个 laptop 类型，文档有 price 和 name 两个字段，在映射中声明一个 percolator 类型的 query，命令如下：

PUT my-index
+{
+	"mappings": {
+		"laptop": {
+			"properties": {
+				"price": { "type": "long" },
+				"name": { "type": "text" }
+			},
+			"queries": {
+				"properties": {
+					"query": { "type": "percolator" }
+				}
+			}
+		}
+	}
+}
+

注册一个 bool query，bool query 中包含一个 range query，要求 price 字段的取值小于等于 10000，并且 name 字段中含有关键词 macbook：

PUT /my-index/queries/1?refresh
+{
+	"query": {
+		"bool": {
+			"must": [{
+				"range": { "price": { "lte": 10000 } }
+			}, {
+				"match": { "name": "macbook" }
+			}]
+		}
+	}
+}
+

通过文档查询 query：

GET /my-index/_search
+{
+	"query": {
+		"percolate": {
+			"field": "query",
+			"document_type": "laptop",
+			"document": {
+				"price": 9999,
+				"name": "macbook pro on sale"
+			}
+		}
+	}
+}
+

文档符合 query 中的条件，返回结果中可以查到上文中注册的 bool query。percolate query 的这种特性适用于数据分类、数据路由、事件监控和预警等场景。

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#查询
上次更新: 2023/06/29, 22:27:04
Elasticsearch 索引
Elasticsearch 高亮搜索及显示

+ ← + Elasticsearch 高亮搜索及显示→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/8448de/index.html b/pages/8448de/index.html new file mode 100644 index 00000000..a903787b --- /dev/null +++ b/pages/8448de/index.html @@ -0,0 +1,69 @@ + + + + + + ShardingSphere Jdbc | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-12-28
目录

ShardingSphere Jdbc

# ShardingSphere Jdbc

# 简介

shardingsphere-jdbc 定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

  • 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。
  • 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。
  • 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，Oracle，SQLServer，PostgreSQL 以及任何遵循 SQL92 标准的数据库。

img

# 快速入门

# 引入 maven 依赖

<dependency>
+    <groupId>org.apache.shardingsphere</groupId>
+    <artifactId>shardingsphere-jdbc-core</artifactId>
+    <version>${latest.release.version}</version>
+</dependency>
+

注意：请将 ${latest.release.version} 更改为实际的版本号。

# 规则配置

ShardingSphere-JDBC 可以通过 Java，YAML，Spring 命名空间和 Spring Boot Starter 这 4 种方式进行配置，开发者可根据场景选择适合的配置方式。 详情请参见配置手册 (opens new window)。

# 创建数据源

通过 ShardingSphereDataSourceFactory 工厂和规则配置对象获取 ShardingSphereDataSource。 该对象实现自 JDBC 的标准 DataSource 接口，可用于原生 JDBC 开发，或使用 JPA, MyBatis 等 ORM 类库。

DataSource dataSource = ShardingSphereDataSourceFactory.createDataSource(dataSourceMap, configurations, properties);
+

# 概念和功能

单一数据节点难于满足互联网的海量数据场景。

从性能方面来说，由于关系型数据库大多采用 B+ 树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的 IO 次数增加，进而导致查询性能的下降；同时，高并发访问请求也使得集中式数据库成为系统的最大瓶颈。

在传统的关系型数据库无法满足互联网场景需要的情况下，将数据存储至原生支持分布式的 NoSQL 的尝试越来越多。 但 NoSQL 对 SQL 的不兼容性以及生态圈的不完善，使得它们在与关系型数据库的博弈中始终无法完成致命一击，而关系型数据库的地位却依然不可撼动。

数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。数据分片的有效手段是对关系型数据库进行分库和分表。分库和分表均可以有效的避免由数据量超过可承受阈值而产生的查询瓶颈。 除此之外，分库还能够用于有效的分散对数据库单点的访问量；分表虽然无法缓解数据库压力，但却能够提供尽量将分布式事务转化为本地事务的可能，一旦涉及到跨库的更新操作，分布式事务往往会使问题变得复杂。 使用多主多从的分片方式，可以有效的避免数据单点，从而提升数据架构的可用性。

通过分库和分表进行数据的拆分来使得各个表的数据量保持在阈值以下，以及对流量进行疏导应对高访问量，是应对高并发和海量数据系统的有效手段。 数据分片的拆分方式又分为垂直分片和水平分片。

# 垂直分片

按照业务拆分的方式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。 在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库中，从而将压力分散至不同的数据库。 下图展示了根据业务需要，将用户表和订单表垂直分片到不同的数据库的方案。

垂直分片 (opens new window)

垂直分片往往需要对架构和设计进行调整。通常来讲，是来不及应对互联网业务需求快速变化的；而且，它也并无法真正的解决单点瓶颈。 垂直拆分可以缓解数据量和访问量带来的问题，但无法根治。如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。

# 水平分片

水平分片又称为横向拆分。 相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。 例如：根据主键分片，偶数主键的记录放入 0 库（或表），奇数主键的记录放入 1 库（或表），如下图所示。

水平分片 (opens new window)

水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。

# 数据分片带来的问题

  • 数据路由：需要知道数据需要从哪个具体的数据库的分表中获取。
  • SQL 不兼容：分表导致表名称的修改，或者分页、排序、聚合、分组等操作的不正确处理。
  • 跨库事务：合理采用分表，可以在降低单表数据量的情况下，尽量使用本地事务，善于使用同库不同表可有效避免分布式事务带来的麻烦。 在不能避免跨库事务的场景，有些业务仍然需要保持事务的一致性。 而基于 XA 的分布式事务由于在并发度高的场景中性能无法满足需要，并未被互联网巨头大规模使用，他们大多采用最终一致性的柔性事务代替强一致事务。

# ShardingSphere 内核剖析

ShardingSphere 的 3 个产品的数据分片主要流程是完全一致的。 核心由 SQL 解析 => 执行器优化 => SQL 路由 => SQL 改写 => SQL 执行 => 结果归并的流程组成。

img

  • QL 解析：分为词法解析和语法解析。 先通过词法解析器将 SQL 拆分为一个个不可再分的单词。再使用语法解析器对 SQL 进行理解，并最终提炼出解析上下文。 解析上下文包括表、选择项、排序项、分组项、聚合函数、分页信息、查询条件以及可能需要修改的占位符的标记。
  • 执行器优化：合并和优化分片条件，如 OR 等。
  • SQL 路由：根据解析上下文匹配用户配置的分片策略，并生成路由路径。目前支持分片路由和广播路由。
  • SQL 改写：将 SQL 改写为在真实数据库中可以正确执行的语句。SQL 改写分为正确性改写和优化改写。
  • SQL 执行：通过多线程执行器异步执行。
  • 结果归并：将多个执行结果集归并以便于通过统一的 JDBC 接口输出。结果归并包括流式归并、内存归并和使用装饰模式的追加归并这几种方式。

# 解析引擎

# 抽象语法树

解析过程分为词法解析和语法解析。 词法解析器用于将 SQL 拆解为不可再分的原子符号，称为 Token。并根据不同数据库方言所提供的字典，将其归类为关键字，表达式，字面量和操作符。 再使用语法解析器将 SQL 转换为抽象语法树。

例如，以下 SQL：

SELECT id, name FROM t_user WHERE status = 'ACTIVE' AND age > 18
+

解析之后的为抽象语法树见下图。

SQL抽象语法树 (opens new window)

为了便于理解，抽象语法树中的关键字的 Token 用绿色表示，变量的 Token 用红色表示，灰色表示需要进一步拆分。

最后，通过对抽象语法树的遍历去提炼分片所需的上下文，并标记有可能需要改写的位置。 供分片使用的解析上下文包含查询选择项（Select Items）、表信息（Table）、分片条件（Sharding Condition）、自增主键信息（Auto increment Primary Key）、排序信息（Order By）、分组信息（Group By）以及分页信息（Limit、Rownum、Top）。 SQL 的一次解析过程是不可逆的，一个个 Token 按 SQL 原本的顺序依次进行解析，性能很高。 考虑到各种数据库 SQL 方言的异同，在解析模块提供了各类数据库的 SQL 方言字典。

# SQL 解析引擎

SQL 解析作为分库分表类产品的核心，其性能和兼容性是最重要的衡量指标。 ShardingSphere 的 SQL 解析器经历了 3 代产品的更新迭代。

第一代 SQL 解析器为了追求性能与快速实现，在 1.4.x 之前的版本使用 Druid 作为 SQL 解析器。经实际测试，它的性能远超其它解析器。

第二代 SQL 解析器从 1.5.x 版本开始，ShardingSphere 采用完全自研的 SQL 解析引擎。 由于目的不同，ShardingSphere 并不需要将 SQL 转为一颗完全的抽象语法树，也无需通过访问器模式进行二次遍历。它采用对 SQL 半理解的方式，仅提炼数据分片需要关注的上下文，因此 SQL 解析的性能和兼容性得到了进一步的提高。

第三代 SQL 解析器则从 3.0.x 版本开始，ShardingSphere 尝试使用 ANTLR 作为 SQL 解析的引擎，并计划根据 DDL -> TCL -> DAL –> DCL -> DML –>DQL 这个顺序，依次替换原有的解析引擎，目前仍处于替换迭代中。 使用 ANTLR 的原因是希望 ShardingSphere 的解析引擎能够更好的对 SQL 进行兼容。对于复杂的表达式、递归、子查询等语句，虽然 ShardingSphere 的分片核心并不关注，但是会影响对于 SQL 理解的友好度。 经过实例测试，ANTLR 解析 SQL 的性能比自研的 SQL 解析引擎慢 3-10 倍左右。为了弥补这一差距，ShardingSphere 将使用 PreparedStatement 的 SQL 解析的语法树放入缓存。 因此建议采用 PreparedStatement 这种 SQL 预编译的方式提升性能。

第三代 SQL 解析引擎的整体结构划分如下图所示。

解析引擎结构 (opens new window)

# 路由引擎

# 改写引擎

# 执行引擎

# 归并引擎

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#中间件#分库分表
上次更新: 2023/06/29, 22:27:04
ShardingSphere 简介
版本管理中间件 Flyway

+ ← + 版本管理中间件 Flyway→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/88c7d3/index.html b/pages/88c7d3/index.html new file mode 100644 index 00000000..dafdf1a1 --- /dev/null +++ b/pages/88c7d3/index.html @@ -0,0 +1,407 @@ + + + + + + MongoDB 建模示例 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-12
目录

MongoDB 建模示例

# MongoDB 建模示例

# 关系型模型

# 嵌入式文档一对一关系模型

# 嵌入式文档一对一关系模型 - 嵌入式文档模式

// patron document
+{
+   _id: "joe",
+   name: "Joe Bookreader"
+}
+
+// address document
+{
+   patron_id: "joe", // reference to patron document
+   street: "123 Fake Street",
+   city: "Faketon",
+   state: "MA",
+   zip: "12345"
+}
+

合并为：

{
+  "_id": "joe",
+  "name": "Joe Bookreader",
+  "address": {
+    "street": "123 Fake Street",
+    "city": "Faketon",
+    "state": "MA",
+    "zip": "12345"
+  }
+}
+

# 嵌入式文档一对一关系模型 - 子集模式

假设，有一个用于描述电影信息的 collection 定义：

{
+  "_id": 1,
+  "title": "The Arrival of a Train",
+  "year": 1896,
+  "runtime": 1,
+  "released": ISODate("01-25-1896"),
+  "poster": "http://ia.media-imdb.com/images/M/MV5BMjEyNDk5MDYzOV5BMl5BanBnXkFtZTgwNjIxMTEwMzE@._V1_SX300.jpg",
+  "plot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, ...",
+  "fullplot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, the line dissolves. The doors of the railway-cars open, and people on the platform help passengers to get off.",
+  "lastupdated": ISODate("2015-08-15T10:06:53"),
+  "type": "movie",
+  "directors": ["Auguste Lumière", "Louis Lumière"],
+  "imdb": {
+    "rating": 7.3,
+    "votes": 5043,
+    "id": 12
+  },
+  "countries": ["France"],
+  "genres": ["Documentary", "Short"],
+  "tomatoes": {
+    "viewer": {
+      "rating": 3.7,
+      "numReviews": 59
+    },
+    "lastUpdated": ISODate("2020-01-09T00:02:53")
+  }
+}
+

在应用中，有的场景只需要显示电影的简单浏览信息，不需要显示类似 fullplot、poster 这样的详细信息。因为，我们可以考虑将原结构一份为二，并通过 id 字段关联起来。

用于展示摘要信息的 movie collection

// movie collection
+
+{
+  "_id": 1,
+  "title": "The Arrival of a Train",
+  "year": 1896,
+  "runtime": 1,
+  "released": ISODate("1896-01-25"),
+  "type": "movie",
+  "directors": ["Auguste Lumière", "Louis Lumière"],
+  "countries": ["France"],
+  "genres": ["Documentary", "Short"]
+}
+

用于展示细节信息的 movie_details collection

// movie_details collection
+
+{
+  "_id": 156,
+  "movie_id": 1, // reference to the movie collection
+  "poster": "http://ia.media-imdb.com/images/M/MV5BMjEyNDk5MDYzOV5BMl5BanBnXkFtZTgwNjIxMTEwMzE@._V1_SX300.jpg",
+  "plot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, ...",
+  "fullplot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, the line dissolves. The doors of the railway-cars open, and people on the platform help passengers to get off.",
+  "lastupdated": ISODate("2015-08-15T10:06:53"),
+  "imdb": {
+    "rating": 7.3,
+    "votes": 5043,
+    "id": 12
+  },
+  "tomatoes": {
+    "viewer": {
+      "rating": 3.7,
+      "numReviews": 59
+    },
+    "lastUpdated": ISODate("2020-01-29T00:02:53")
+  }
+}
+

# 嵌入式文档一对多关系模型

# 嵌入式文档一对多关系模型 - 嵌入式文档模式

// patron document
+{
+   _id: "joe",
+   name: "Joe Bookreader"
+}
+
+// address documents
+{
+   patron_id: "joe", // reference to patron document
+   street: "123 Fake Street",
+   city: "Faketon",
+   state: "MA",
+   zip: "12345"
+}
+
+{
+   patron_id: "joe",
+   street: "1 Some Other Street",
+   city: "Boston",
+   state: "MA",
+   zip: "12345"
+}
+

合并为：

{
+  "_id": "joe",
+  "name": "Joe Bookreader",
+  "addresses": [
+    {
+      "street": "123 Fake Street",
+      "city": "Faketon",
+      "state": "MA",
+      "zip": "12345"
+    },
+    {
+      "street": "1 Some Other Street",
+      "city": "Boston",
+      "state": "MA",
+      "zip": "12345"
+    }
+  ]
+}
+

# 嵌入式文档一对多关系模型 - 子集模式

考虑一个电商网站用于表示商品的 collection：

{
+  "_id": 1,
+  "name": "Super Widget",
+  "description": "This is the most useful item in your toolbox.",
+  "price": { "value": NumberDecimal("119.99"), "currency": "USD" },
+  "reviews": [
+    {
+      "review_id": 786,
+      "review_author": "Kristina",
+      "review_text": "This is indeed an amazing widget.",
+      "published_date": ISODate("2019-02-18")
+    },
+    {
+      "review_id": 785,
+      "review_author": "Trina",
+      "review_text": "Nice product. Slow shipping.",
+      "published_date": ISODate("2019-02-17")
+    },
+    ...{
+      "review_id": 1,
+      "review_author": "Hans",
+      "review_text": "Meh, it's okay.",
+      "published_date": ISODate("2017-12-06")
+    }
+  ]
+}
+

评论按时间倒序排列。 当用户访问产品页面时，应用程序将加载十条最近的评论。可以将集合分为两个集合，而不是与产品一起存储所有评论：

产品集合存储有关每个产品的信息，包括产品的十个最新评论：

{
+  "_id": 1,
+  "name": "Super Widget",
+  "description": "This is the most useful item in your toolbox.",
+  "price": { "value": NumberDecimal("119.99"), "currency": "USD" },
+  "reviews": [
+    {
+      "review_id": 786,
+      "review_author": "Kristina",
+      "review_text": "This is indeed an amazing widget.",
+      "published_date": ISODate("2019-02-18")
+    }
+    ...
+    {
+      "review_id": 776,
+      "review_author": "Pablo",
+      "review_text": "Amazing!",
+      "published_date": ISODate("2019-02-16")
+    }
+  ]
+}
+

review collection 存储所有的评论

{
+  "review_id": 786,
+  "product_id": 1,
+  "review_author": "Kristina",
+  "review_text": "This is indeed an amazing widget.",
+  "published_date": ISODate("2019-02-18")
+}
+{
+  "review_id": 785,
+  "product_id": 1,
+  "review_author": "Trina",
+  "review_text": "Nice product. Slow shipping.",
+  "published_date": ISODate("2019-02-17")
+}
+...
+{
+  "review_id": 1,
+  "product_id": 1,
+  "review_author": "Hans",
+  "review_text": "Meh, it's okay.",
+  "published_date": ISODate("2017-12-06")
+}
+

# 引用式文档一对多关系模型

考虑以下映射出版商和书籍关系的示例。

该示例说明了引用式文档的优点，以避免重复发布者信息。

{
+   title: "MongoDB: The Definitive Guide",
+   author: [ "Kristina Chodorow", "Mike Dirolf" ],
+   published_date: ISODate("2010-09-24"),
+   pages: 216,
+   language: "English",
+   publisher: {
+              name: "O'Reilly Media",
+              founded: 1980,
+              location: "CA"
+            }
+}
+
+{
+   title: "50 Tips and Tricks for MongoDB Developer",
+   author: "Kristina Chodorow",
+   published_date: ISODate("2011-05-06"),
+   pages: 68,
+   language: "English",
+   publisher: {
+              name: "O'Reilly Media",
+              founded: 1980,
+              location: "CA"
+            }
+}
+

为避免重复出版商数据，可以使用引用型文档，并将出版商信息与书本分开保存。 使用引用时，关系的增长决定了将引用存储在何处。 如果每个出版商的图书数量很少且增长有限，则有时将图书参考存储在出版商文档中可能会很有用。 否则，如果每个发布者的书籍数量不受限制，则此数据模型将导致可变的，不断增长的数组，如以下示例所示：

{
+   name: "O'Reilly Media",
+   founded: 1980,
+   location: "CA",
+   books: [123456789, 234567890, ...]
+}
+
+{
+    _id: 123456789,
+    title: "MongoDB: The Definitive Guide",
+    author: [ "Kristina Chodorow", "Mike Dirolf" ],
+    published_date: ISODate("2010-09-24"),
+    pages: 216,
+    language: "English"
+}
+
+{
+   _id: 234567890,
+   title: "50 Tips and Tricks for MongoDB Developer",
+   author: "Kristina Chodorow",
+   published_date: ISODate("2011-05-06"),
+   pages: 68,
+   language: "English"
+}
+

为了避免可变的，增长的数组，请将发行者参考存储在书籍文档中：

{
+   _id: "oreilly",
+   name: "O'Reilly Media",
+   founded: 1980,
+   location: "CA"
+}
+
+{
+   _id: 123456789,
+   title: "MongoDB: The Definitive Guide",
+   author: [ "Kristina Chodorow", "Mike Dirolf" ],
+   published_date: ISODate("2010-09-24"),
+   pages: 216,
+   language: "English",
+   publisher_id: "oreilly"
+}
+
+{
+   _id: 234567890,
+   title: "50 Tips and Tricks for MongoDB Developer",
+   author: "Kristina Chodorow",
+   published_date: ISODate("2011-05-06"),
+   pages: 68,
+   language: "English",
+   publisher_id: "oreilly"
+}
+

# 树形结构模型

img

# 具有父节点的树形结构模型

上图结构可以用父引用来表示：

db.categories.insertMany([
+  { "_id": "MongoDB", "parent": "Databases" },
+  { "_id": "dbm", "parent": "Databases" },
+  { "_id": "Databases", "parent": "Programming" },
+  { "_id": "Languages", "parent": "Programming" },
+  { "_id": "Programming", "parent": "Books" },
+  { "_id": "Books", "parent": null }
+])
+

  • 检索节点的父节点：

    db.categories.findOne( { _id: "MongoDB" } ).parent
+

  • 可以在父字段上创建索引以启用父节点的快速搜索：

    db.categories.createIndex( { parent: 1 } )
+

  • 可以通过父字段查询找到其直接子节点：

    db.categories.find( { parent: "Databases" } )
+

  • 检索子树，可以参考： $graphLookup (opens new window).

# 具有子节点的树形结构模型

db.categories.insertMany([
+  { "_id": "MongoDB", "children": [] },
+  { "_id": "dbm", "children": [] },
+  { "_id": "Databases", "children": ["MongoDB", "dbm"] },
+  { "_id": "Languages", "children": [] },
+  { "_id": "Programming", "children": ["Databases", "Languages"] },
+  { "_id": "Books", "children": ["Programming"] }
+])
+

  • 检索节点的 children：

    db.categories.findOne( { _id: "Databases" } ).children
+

  • 可以在 children 字段上创建索引以启用子节点的快速搜索：

    db.categories.createIndex( { children: 1 } )
+

  • 可以在 children 字段中查询节点，以找到其父节点及其兄弟节点：

    db.categories.find( { children: "MongoDB" } )
+

# 具有祖先的树形结构模型

db.categories.insertMany([
+  {
+    "_id": "MongoDB",
+    "ancestors": ["Books", "Programming", "Databases"],
+    "parent": "Databases"
+  },
+  {
+    "_id": "dbm",
+    "ancestors": ["Books", "Programming", "Databases"],
+    "parent": "Databases"
+  },
+  {
+    "_id": "Databases",
+    "ancestors": ["Books", "Programming"],
+    "parent": "Programming"
+  },
+  {
+    "_id": "Languages",
+    "ancestors": ["Books", "Programming"],
+    "parent": "Programming"
+  },
+  { "_id": "Programming", "ancestors": ["Books"], "parent": "Books" },
+  { "_id": "Books", "ancestors": [], "parent": null }
+])
+

  • 检索节点的祖先或路径的查询是快速而直接的：

    db.categories.findOne({ "_id": "MongoDB" }).ancestors
+

  • 可以在 ancestors 字段上创建索引，以启用祖先节点的快速搜索：

    db.categories.createIndex({ "ancestors": 1 })
+

  • 可以通过 ancestors 字段查询查找其所有后代：

    db.categories.find({ "ancestors": "Programming" })
+

# 具有实体化路径的树形结构模型

db.categories.insertMany([
+  { "_id": "Books", "path": null },
+  { "_id": "Programming", "path": ",Books," },
+  { "_id": "Databases", "path": ",Books,Programming," },
+  { "_id": "Languages", "path": ",Books,Programming," },
+  { "_id": "MongoDB", "path": ",Books,Programming,Databases," },
+  { "_id": "dbm", "path": ",Books,Programming,Databases," }
+])
+

  • 可以查询以检索整个树，并按字段路径排序：

    db.categories.find().sort( { path: 1 } )
+

  • 可以在 path 字段上使用正则表达式来查找 Programming 的后代

    db.categories.find( { path: /,Programming,/ } )
+

  • 可以检索 Books 的后代，其中 Books 也位于层次结构的最高级别：

    db.categories.find( { path: /^,Books,/ } )
+

  • 要在 path 字段上创建索引，请使用以下调用：

    db.categories.createIndex( { path: 1 } )
+

# 具有嵌套集的树形结构模型

img

db.categories.insertMany([
+  { _id: 'Books', parent: 0, left: 1, right: 12 },
+  { _id: 'Programming', parent: 'Books', left: 2, right: 11 },
+  { _id: 'Languages', parent: 'Programming', left: 3, right: 4 },
+  { _id: 'Databases', parent: 'Programming', left: 5, right: 10 },
+  { _id: 'MongoDB', parent: 'Databases', left: 6, right: 7 },
+  { _id: 'dbm', parent: 'Databases', left: 8, right: 9 }
+])
+

可以查询以检索节点的后代：

var databaseCategory = db.categories.findOne({ _id: 'Databases' })
+db.categories.find({
+  left: { $gt: databaseCategory.left },
+  right: { $lt: databaseCategory.right }
+})
+

# 设计模式

# 大文档，很多列，很多索引

解决方案是：列转行

img

# 管理文档不同版本

MongoDB 文档格式非常灵活，势必会带来版本维护上的难度。

解决方案是：可以增加一个版本号字段

  • 快速过滤掉不需要升级的文档
  • 升级时，对不同版本的文档做不同处理

# 统计网页点击量

统计数据精确性要求并不是十分重要。

解决方案：用近似计算

每隔 10 次写一次：

{ "$inc": { "views": 1 } }
+

# 精确统计

解决方案：使用预聚合

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#文档数据库#MongoDB#建模
上次更新: 2023/06/29, 22:27:04
MongoDB 建模
MongoDB 索引

+ ← + MongoDB 索引→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/92df30/index.html b/pages/92df30/index.html new file mode 100644 index 00000000..3423bdd9 --- /dev/null +++ b/pages/92df30/index.html @@ -0,0 +1,191 @@ + + + + + + Logstash 运维 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-16
目录

Logstash 运维

# Logstash 运维

Logstash (opens new window) 是开源的服务器端数据处理管道，能够同时从多个来源采集数据，转换数据，然后将数据发送到您最喜欢的“存储库”中。

# 1. 安装

# 1.1. 安装步骤

安装步骤如下：

（1）在 logstash 官方下载地址 (opens new window)下载所需版本包并解压到本地。

（2）添加一个 logstash.conf 文件，指定要使用的插件以及每个插件的设置。举个简单的例子：

input { stdin { } }
+output {
+  elasticsearch { hosts => ["localhost:9200"] }
+  stdout { codec => rubydebug }
+}
+

（3）运行 bin/logstash -f logstash.conf （Windows 上运行bin/logstash.bat -f logstash.conf）

# 2. 配置

# 2.1. 设置文件

  • logstash.yml：logstash 的默认启动配置文件
  • jvm.options：logstash 的 JVM 配置文件。
  • startup.options (Linux)：包含系统安装脚本在 /usr/share/logstash/bin 中使用的选项为您的系统构建适当的启动脚本。安装 Logstash 软件包时，系统安装脚本将在安装过程结束时执行，并使用 startup.options 中指定的设置来设置用户，组，服务名称和服务描述等选项。

# 2.2. logstash.yml 设置项

节选部分设置项，更多项请参考：https://www.elastic.co/guide/en/logstash/current/logstash-settings-file.html (opens new window)

参数 描述 默认值
node.name 节点名 机器的主机名
path.data Logstash 及其插件用于任何持久性需求的目录。 LOGSTASH_HOME/data
pipeline.workers 同时执行管道的过滤器和输出阶段的工作任务数量。如果发现事件正在备份，或 CPU 未饱和，请考虑增加此数字以更好地利用机器处理能力。 Number of the host’s CPU cores
pipeline.batch.size 尝试执行过滤器和输出之前，单个工作线程从输入收集的最大事件数量。较大的批量处理大小一般来说效率更高，但是以增加的内存开销为代价。您可能必须通过设置 LS_HEAP_SIZE 变量来有效使用该选项来增加 JVM 堆大小。 125
pipeline.batch.delay 创建管道事件批处理时，在将一个尺寸过小的批次发送给管道工作任务之前，等待每个事件需要多长时间（毫秒）。 5
pipeline.unsafe_shutdown 如果设置为 true，则即使在内存中仍存在 inflight 事件时，也会强制 Logstash 在关闭期间退出。默认情况下，Logstash 将拒绝退出，直到所有接收到的事件都被推送到输出。启用此选项可能会导致关机期间数据丢失。 false
path.config 主管道的 Logstash 配置路径。如果您指定一个目录或通配符，配置文件将按字母顺序从目录中读取。 Platform-specific. See [dir-layout] (opens new window).
config.string 包含用于主管道的管道配置的字符串。使用与配置文件相同的语法。 None
config.test_and_exit 设置为 true 时，检查配置是否有效，然后退出。请注意，使用此设置不会检查 grok 模式的正确性。 Logstash 可以从目录中读取多个配置文件。如果将此设置与 log.level：debug 结合使用，则 Logstash 将记录组合的配置文件，并注掉其源文件的配置块。 false
config.reload.automatic 设置为 true 时，定期检查配置是否已更改，并在配置更改时重新加载配置。这也可以通过 SIGHUP 信号手动触发。 false
config.reload.interval Logstash 检查配置文件更改的时间间隔。 3s
config.debug 设置为 true 时，将完全编译的配置显示为调试日志消息。您还必须设置log.level：debug。警告：日志消息将包括任何传递给插件配置作为明文的“密码”选项，并可能导致明文密码出现在您的日志！ false
config.support_escapes 当设置为 true 时，带引号的字符串将处理转义字符。 false
modules 配置时，模块必须处于上表所述的嵌套 YAML 结构中。 None
http.host 绑定地址 "127.0.0.1"
http.port 绑定端口 9600
log.level 日志级别。有效选项：fatal > error > warn > info > debug > trace info
log.format 日志格式。json （JSON 格式）或 plain （原对象） plain
path.logs Logstash 自身日志的存储路径 LOGSTASH_HOME/logs
path.plugins 在哪里可以找到自定义的插件。您可以多次指定此设置以包含多个路径。

# 3. 启动

# 3.1. 命令行

通过命令行启动 logstash 的方式如下：

bin/logstash [options]
+

其中 options 是您可以指定用于控制 Logstash 执行的命令行标志。

在命令行上设置的任何标志都会覆盖 Logstash 设置文件（logstash.yml）中的相应设置，但设置文件本身不会更改。

注

虽然可以通过指定命令行参数的方式，来控制 logstash 的运行方式，但显然这么做很麻烦。

建议通过指定配置文件的方式，来控制 logstash 运行，启动命令如下：

bin/logstash -f logstash.conf
+

若想了解更多的命令行参数细节，请参考：https://www.elastic.co/guide/en/logstash/current/running-logstash-command-line.html (opens new window)

# 3.2. 配置文件

上节，我们了解到，logstash 可以执行 bin/logstash -f logstash.conf ，按照配置文件中的参数去覆盖默认设置文件（logstash.yml）中的设置。

这节，我们就来学习一下这个配置文件如何配置参数。

# 3.2.1. 配置文件结构

在工作原理一节中，我们已经知道了 Logstash 主要有三个工作阶段 input 、filter、output。而 logstash 配置文件文件结构也与之相对应：

input {}
+
+filter {}
+
+output {}
+

每个部分都包含一个或多个插件的配置选项。如果指定了多个过滤器，则会按照它们在配置文件中的显示顺序应用它们。

# 3.2.2. 插件配置

插件的配置由插件名称和插件的一个设置块组成。

下面的例子中配置了两个输入文件配置：

input {
+  file {
+    path => "/var/log/messages"
+    type => "syslog"
+  }
+
+  file {
+    path => "/var/log/apache/access.log"
+    type => "apache"
+  }
+}
+

您可以配置的设置因插件类型而异。你可以参考： Input Plugins (opens new window), Output Plugins (opens new window), Filter Plugins (opens new window), 和 Codec Plugins (opens new window) 。

# 3.2.3. 值类型

一个插件可以要求设置的值是一个特定的类型，比如布尔值，列表或哈希值。以下值类型受支持。

  • Array
  users => [ {id => 1, name => bob}, {id => 2, name => jane} ]
+
  • Lists
  path => [ "/var/log/messages", "/var/log/*.log" ]
+  uris => [ "http://elastic.co", "http://example.net" ]
+
  • Boolean
  ssl_enable => true
+
  • Bytes
  my_bytes => "1113"   # 1113 bytes
+  my_bytes => "10MiB"  # 10485760 bytes
+  my_bytes => "100kib" # 102400 bytes
+  my_bytes => "180 mb" # 180000000 bytes
+
  • Codec
  codec => "json"
+
  • Hash
match => {
+  "field1" => "value1"
+  "field2" => "value2"
+  ...
+}
+
  • Number
  port => 33
+
  • Password
  my_password => "password"
+
  • URI
  my_uri => "http://foo:bar@example.net"
+
  • Path
  my_path => "/tmp/logstash"
+

  • String

  • 转义字符

# 4. 插件

# 4.1. input

Logstash 支持各种输入选择 ，可以在同一时间从众多常用来源捕捉事件。能够以连续的流式传输方式，轻松地从您的日志、指标、Web 应用、数据存储以及各种 AWS 服务采集数据。

# 4.1.1. 常用 input 插件

  • file：从文件系统上的文件读取，就像 UNIX 命令 tail -0F 一样
  • **syslog：**在众所周知的端口 514 上侦听系统日志消息，并根据 RFC3164 格式进行解析
  • **redis：**从 redis 服务器读取，使用 redis 通道和 redis 列表。 Redis 经常用作集中式 Logstash 安装中的“代理”，它将来自远程 Logstash“托运人”的 Logstash 事件排队。
  • **beats：**处理由 Filebeat 发送的事件。

更多详情请见：Input Plugins (opens new window)

# 4.2. filter

过滤器是 Logstash 管道中的中间处理设备。如果符合特定条件，您可以将条件过滤器组合在一起，对事件执行操作。

# 4.2.1. 常用 filter 插件

  • **grok：**解析和结构任意文本。 Grok 目前是 Logstash 中将非结构化日志数据解析为结构化和可查询的最佳方法。

  • **mutate：**对事件字段执行一般转换。您可以重命名，删除，替换和修改事件中的字段。

  • **drop：**完全放弃一个事件，例如调试事件。

  • **clone：**制作一个事件的副本，可能会添加或删除字段。

  • **geoip：**添加有关 IP 地址的地理位置的信息（也可以在 Kibana 中显示惊人的图表！）

更多详情请见：Filter Plugins (opens new window)

# 4.3. output

输出是 Logstash 管道的最后阶段。一个事件可以通过多个输出，但是一旦所有输出处理完成，事件就完成了执行。

# 4.3.1. 常用 output 插件

  • **elasticsearch：**将事件数据发送给 Elasticsearch（推荐模式）。
  • **file：**将事件数据写入文件或磁盘。
  • **graphite：**将事件数据发送给 graphite（一个流行的开源工具，存储和绘制指标。 http://graphite.readthedocs.io/en/latest/）。 (opens new window)
  • **statsd：**将事件数据发送到 statsd （这是一种侦听统计数据的服务，如计数器和定时器，通过 UDP 发送并将聚合发送到一个或多个可插入的后端服务）。

更多详情请见：Output Plugins (opens new window)

# 4.4. codec

用于格式化对应的内容。

# 4.4.1. 常用 codec 插件

  • **json：**以 JSON 格式对数据进行编码或解码。
  • **multiline：**将多行文本事件（如 java 异常和堆栈跟踪消息）合并为单个事件。

更多插件请见：Codec Plugins (opens new window)

# 5. 实战

前面的内容都是对 Logstash 的介绍和原理说明。接下来，我们来实战一些常见的应用场景。

# 5.1. 传输控制台数据

stdin input 插件从标准输入读取事件。这是最简单的 input 插件，一般用于测试场景。

应用

（1）创建 logstash-input-stdin.conf ：

input { stdin { } }
+output {
+  elasticsearch { hosts => ["localhost:9200"] }
+  stdout { codec => rubydebug }
+}
+

更多配置项可以参考：https://www.elastic.co/guide/en/logstash/current/plugins-inputs-stdin.html (opens new window)

（2）执行 logstash，使用 -f 来指定你的配置文件：

bin/logstash -f logstash-input-stdin.conf
+

# 5.2. 传输 logback 日志

elk 默认使用的 Java 日志工具是 log4j2 ，并不支持 logback 和 log4j。

想使用 logback + logstash ，可以使用 logstash-logback-encoder (opens new window) 。logstash-logback-encoder (opens new window) 提供了 UDP / TCP / 异步方式来传输日志数据到 logstash。

如果你使用的是 log4j ，也不是不可以用这种方式，只要引入桥接 jar 包即可。如果你对 log4j 、logback ，或是桥接 jar 包不太了解，可以参考我的这篇博文：细说 Java 主流日志工具库 (opens new window) 。

# 5.2.1. TCP 应用

logstash 配置：

（1）创建 logstash-input-tcp.conf ：

input {
+  # stdin { }
+  tcp {
+    # host:port就是上面appender中的 destination，
+ # 这里其实把logstash作为服务，开启9250端口接收logback发出的消息
+    host => "127.0.0.1" port => 9250 mode => "server" tags => ["tags"] codec => json_lines
+  }
+}
+output {
+  elasticsearch { hosts => ["localhost:9200"] }
+  stdout { codec => rubydebug }
+}
+

更多配置项可以参考：https://www.elastic.co/guide/en/logstash/current/plugins-inputs-tcp.html (opens new window)

（2）执行 logstash，使用 -f 来指定你的配置文件：bin/logstash -f logstash-input-udp.conf

java 应用配置：

（1）在 Java 应用的 pom.xml 中引入 jar 包：

<dependency>
+ <groupId>net.logstash.logback</groupId>
+ <artifactId>logstash-logback-encoder</artifactId>
+ <version>4.11</version>
+</dependency>
+
+<!-- logback 依赖包 -->
+<dependency>
+ <groupId>ch.qos.logback</groupId>
+ <artifactId>logback-core</artifactId>
+ <version>1.2.3</version>
+</dependency>
+<dependency>
+ <groupId>ch.qos.logback</groupId>
+ <artifactId>logback-classic</artifactId>
+ <version>1.2.3</version>
+</dependency>
+<dependency>
+ <groupId>ch.qos.logback</groupId>
+ <artifactId>logback-access</artifactId>
+ <version>1.2.3</version>
+</dependency>
+

（2）接着，在 logback.xml 中添加 appender

<appender name="ELK-TCP" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
+ <!--
+ destination 是 logstash 服务的 host:port，
+ 相当于和 logstash 建立了管道，将日志数据定向传输到 logstash
+ -->
+ <destination>192.168.28.32:9251</destination>
+ <encoder charset="UTF-8" class="net.logstash.logback.encoder.LogstashEncoder"/>
+</appender>
+<logger name="io.github.dunwu.spring" level="TRACE" additivity="false">
+ <appender-ref ref="ELK-TCP" />
+</logger>
+

大功告成，此后，io.github.dunwu.spring 包中的 TRACE 及以上级别的日志信息都会被定向输出到 logstash 服务。

img

接下来，就是 logback 的具体使用 ，如果对此不了解，不妨参考一下我的这篇博文：细说 Java 主流日志工具库 (opens new window) 。

实例：我的 logback.xml (opens new window)

# 5.2.2. UDP 应用

UDP 和 TCP 的使用方式大同小异。

logstash 配置：

（1）创建 logstash-input-udp.conf ：

input {
+udp {
+  port => 9250
+  codec => json
+}
+}
+output {
+ elasticsearch { hosts => ["localhost:9200"] }
+ stdout { codec => rubydebug }
+}
+

更多配置项可以参考：https://www.elastic.co/guide/en/logstash/current/plugins-inputs-udp.html (opens new window)

（2）执行 logstash，使用 -f 来指定你的配置文件：bin/logstash -f logstash-input-udp.conf

java 应用配置：

（1）在 Java 应用的 pom.xml 中引入 jar 包：

与 TCP 应用 一节中的引入依赖包完全相同。

（2）接着，在 logback.xml 中添加 appender

<appender name="ELK-UDP" class="net.logstash.logback.appender.LogstashSocketAppender">
+  <host>192.168.28.32</host>
+  <port>9250</port>
+</appender>
+<logger name="io.github.dunwu.spring" level="TRACE" additivity="false">
+  <appender-ref ref="ELK-UDP" />
+</logger>
+

（3）接下来，就是 logback 的具体使用 ，如果对此不了解，不妨参考一下我的这篇博文：细说 Java 主流日志工具库 (opens new window) 。

实例：我的 logback.xml (opens new window)

# 5.3. 传输文件

在 Java Web 领域，需要用到一些重要的工具，例如 Tomcat 、Nginx 、Mysql 等。这些不属于业务应用，但是它们的日志数据对于定位问题、分析统计同样很重要。这时无法使用 logback 方式将它们的日志传输到 logstash。

如何采集这些日志文件呢？别急，你可以使用 logstash 的 file input 插件。

需要注意的是，传输文件这种方式，必须在日志所在的机器上部署 logstash 。

应用

logstash 配置

（1）创建 logstash-input-file.conf ：

input {
+ file {
+  path => ["/var/log/nginx/access.log"]
+  type => "nginx-access-log"
+  start_position => "beginning"
+ }
+}
+
+output {
+ if [type] == "nginx-access-log" {
+  elasticsearch {
+   hosts => ["localhost:9200"]
+   index => "nginx-access-log"
+  }
+ }
+}
+

（2）执行 logstash，使用 -f 来指定你的配置文件：bin/logstash -f logstash-input-file.conf

更多配置项可以参考：https://www.elastic.co/guide/en/logstash/current/plugins-inputs-file.html (opens new window)

# 6. 小技巧

# 6.1. 启动、终止应用

如果你的 logstash 每次都是通过指定配置文件方式启动。不妨建立一个启动脚本。

# cd xxx 进入 logstash 安装目录下的 bin 目录
+logstash -f logstash.conf
+

如果你的 logstash 运行在 linux 系统下，不妨使用 nohup 来启动一个守护进程。这样做的好处在于，即使关闭终端，应用仍会运行。

创建 startup.sh：

nohup ./logstash -f logstash.conf >> nohup.out 2>&1 &
+

终止应用没有什么好方法，你只能使用 ps -ef | grep logstash ，查出进程，将其 kill 。不过，我们可以写一个脚本来干这件事：

创建 shutdown.sh：

脚本不多解释，请自行领会作用。

PID=`ps -ef | grep logstash | awk '{ print $2}' | head -n 1`
+kill -9 ${PID}
+

# 7. 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elastic#Logstash
上次更新: 2023/06/29, 22:27:04
Elastic 技术栈之 Logstash

+ ← +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/94e9d6/index.html b/pages/94e9d6/index.html new file mode 100644 index 00000000..8238161a --- /dev/null +++ b/pages/94e9d6/index.html @@ -0,0 +1,149 @@ + + + + + + Redis 应用指南 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-01-30
目录

Redis 应用指南

# Redis 应用指南

# 一、Redis 简介

Redis 是速度非常快的非关系型（NoSQL）内存键值数据库，可以存储键和五种不同类型的值之间的映射。

键的类型只能为字符串，值支持的五种类型数据类型为：字符串、列表、集合、有序集合、散列表。

# Redis 使用场景

  • 缓存 - 将热点数据放到内存中，设置内存的最大使用量以及过期淘汰策略来保证缓存的命中率。
  • 计数器 - Redis 这种内存数据库能支持计数器频繁的读写操作。
  • 应用限流 - 限制一个网站访问流量。
  • 消息队列 - 使用 List 数据类型，它是双向链表。
  • 查找表 - 使用 HASH 数据类型。
  • 交集运算 - 使用 SET 类型，例如求两个用户的共同好友。
  • 排行榜 - 使用 ZSET 数据类型。
  • 分布式 Session - 多个应用服务器的 Session 都存储到 Redis 中来保证 Session 的一致性。
  • 分布式锁 - 除了可以使用 SETNX 实现分布式锁之外，还可以使用官方提供的 RedLock 分布式锁实现。

# Redis 的优势

  • 性能极高 – Redis 能读的速度是 110000 次/s,写的速度是 81000 次/s。
  • 丰富的数据类型 - 支持字符串、列表、集合、有序集合、散列表。
  • 原子 - Redis 的所有操作都是原子性的。单个操作是原子性的。多个操作也支持事务，即原子性，通过 MULTI 和 EXEC 指令包起来。
  • 持久化 - Redis 支持数据的持久化。可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
  • 备份 - Redis 支持数据的备份，即 master-slave 模式的数据备份。
  • 丰富的特性 - Redis 还支持发布订阅, 通知, key 过期等等特性。

# Redis 与 Memcached

Redis 与 Memcached 因为都可以用于缓存，所以常常被拿来做比较，二者主要有以下区别：

数据类型

  • Memcached 仅支持字符串类型；
  • 而 Redis 支持五种不同种类的数据类型，使得它可以更灵活地解决问题。

数据持久化

  • Memcached 不支持持久化；
  • Redis 支持两种持久化策略：RDB 快照和 AOF 日志。

分布式

  • Memcached 不支持分布式，只能通过在客户端使用像一致性哈希这样的分布式算法来实现分布式存储，这种方式在存储和查询时都需要先在客户端计算一次数据所在的节点。
  • Redis Cluster 实现了分布式的支持。

内存管理机制

  • Memcached 将内存分割成特定长度的块来存储数据，以完全解决内存碎片的问题，但是这种方式会使得内存的利用率不高，例如块的大小为 128 bytes，只存储 100 bytes 的数据，那么剩下的 28 bytes 就浪费掉了。
  • 在 Redis 中，并不是所有数据都一直存储在内存中，可以将一些很久没用的 value 交换到磁盘。而 Memcached 的数据则会一直在内存中。

# Redis 为什么快

Redis 单机 QPS 能达到 100000。

Redis 是单线程模型（Redis 6.0 已经支持多线程模型），为什么还能有这么高的并发？

  • Redis 完全基于内存操作。
  • Redis 数据结构简单。
  • 采用单线程，避免线程上下文切换和竞争。
  • 使用 I/O 多路复用模型（非阻塞 I/O）。

I/O 多路复用

I/O 多路复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。

# 二、Redis 数据类型

Redis 基本数据类型：STRING、HASH、LIST、SET、ZSET

Redis 高级数据类型：BitMap、HyperLogLog、GEO

💡 更详细的特性及原理说明请参考：Redis 数据类型和应用

# 三、Redis 内存淘汰

# 内存淘汰要点

  • 最大缓存 - Redis 允许通过 maxmemory 参数来设置内存最大值。

  • 失效时间 - 作为一种定期清理无效数据的重要机制，在 Redis 提供的诸多命令中，EXPIRE、EXPIREAT、PEXPIRE、PEXPIREAT 以及 SETEX 和 PSETEX 均可以用来设置一条键值对的失效时间。而一条键值对一旦被关联了失效时间就会在到期后自动删除（或者说变得无法访问更为准确）。

  • 淘汰策略 - 随着不断的向 Redis 中保存数据，当内存剩余空间无法满足添加的数据时，Redis 内就会施行数据淘汰策略，清除一部分内容然后保证新的数据可以保存到内存中。内存淘汰机制是为了更好的使用内存，用一定得 miss 来换取内存的利用率，保证 Redis 缓存中保存的都是热点数据。

  • 非精准的 LRU - 实际上 Redis 实现的 LRU 并不是可靠的 LRU，也就是名义上我们使用 LRU 算法淘汰键，但是实际上被淘汰的键并不一定是真正的最久没用的。

# 主键过期时间

Redis 可以为每个键设置过期时间，当键过期时，会自动删除该键。

对于散列表这种容器，只能为整个键设置过期时间（整个散列表），而不能为键里面的单个元素设置过期时间。

可以使用 EXPIRE 或 EXPIREAT 来为 key 设置过期时间。

🔔 注意：当 EXPIRE 的时间如果设置的是负数，EXPIREAT 设置的时间戳是过期时间，将直接删除 key。

示例：

redis> SET mykey "Hello"
+"OK"
+redis> EXPIRE mykey 10
+(integer) 1
+redis> TTL mykey
+(integer) 10
+redis> SET mykey "Hello World"
+"OK"
+redis> TTL mykey
+(integer) -1
+redis>
+

# 淘汰策略

内存淘汰只是 Redis 提供的一个功能，为了更好地实现这个功能，必须为不同的应用场景提供不同的策略，内存淘汰策略讲的是为实现内存淘汰我们具体怎么做，要解决的问题包括淘汰键空间如何选择？在键空间中淘汰键如何选择？

Redis 提供了下面几种内存淘汰策略供用户选：

  • noeviction - 当内存使用达到阈值的时候，所有引起申请内存的命令会报错。这是 Redis 默认的策略。
  • allkeys-lru - 在主键空间中，优先移除最近未使用的 key。
  • allkeys-random - 在主键空间中，随机移除某个 key。
  • volatile-lru - 在设置了过期时间的键空间中，优先移除最近未使用的 key。
  • volatile-random - 在设置了过期时间的键空间中，随机移除某个 key。
  • volatile-ttl - 在设置了过期时间的键空间中，具有更早过期时间的 key 优先移除。

# 如何选择淘汰策略

  • 如果数据呈现幂等分布（存在热点数据，部分数据访问频率高，部分数据访问频率低），则使用 allkeys-lru。
  • 如果数据呈现平等分布（数据访问频率大致相同），则使用 allkeys-random。
  • 如果希望使用不同的 TTL 值向 Redis 提示哪些 key 更适合被淘汰，请使用 volatile-ttl。
  • volatile-lru 和 volatile-random 适合既应用于缓存和又应用于持久化存储的场景，然而我们也可以通过使用两个 Redis 实例来达到相同的效果。
  • 将 key 设置过期时间实际上会消耗更多的内存，因此建议使用 allkeys-lru 策略从而更有效率的使用内存。

# 内部实现

Redis 删除失效主键的方法主要有两种：

  • 消极方法（passive way），在主键被访问时如果发现它已经失效，那么就删除它。
  • 主动方法（active way），周期性地从设置了失效时间的主键中选择一部分失效的主键删除。
  • 主动删除：当前已用内存超过 maxmemory 限定时，触发主动清理策略，该策略由启动参数的配置决定主键具体的失效时间全部都维护在 expires 这个字典表中。

# 四、Redis 持久化

Redis 是内存型数据库，为了保证数据在宕机后不会丢失，需要将内存中的数据持久化到硬盘上。

Redis 支持两种持久化方式：RDB 和 AOF。

  • RDB - RDB 即快照方式，它将某个时间点的所有 Redis 数据保存到一个经过压缩的二进制文件（RDB 文件）中。
  • AOF - AOF(Append Only File) 是以文本日志形式将所有写命令追加到 AOF 文件的末尾，以此来记录数据的变化。当服务器重启的时候会重新载入和执行这些命令来恢复原始的数据。AOF 适合作为 热备。

💡 更详细的特性及原理说明请参考：Redis 持久化

# 五、Redis 事件

Redis 服务器是一个事件驱动程序，服务器需要处理两类事件：

  • 文件事件（file event） - Redis 服务器通过套接字（Socket）与客户端或者其它服务器进行通信，文件事件就是对套接字操作的抽象。服务器与客户端（或其他的服务器）的通信会产生文件事件，而服务器通过监听并处理这些事件来完成一系列网络通信操作。
  • 时间事件（time event） - Redis 服务器有一些操作需要在给定的时间点执行，时间事件是对这类定时操作的抽象。

# 文件事件

Redis 基于 Reactor 模式开发了自己的网络时间处理器。

  • Redis 文件事件处理器使用 I/O 多路复用程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
  • 当被监听的套接字准备好执行连接应答、读取、写入、关闭操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

虽然文件事件处理器以单线程方式运行，但通过使用 I/O 多路复用程序来监听多个套接字，文件事件处理器实现了高性能的网络通信模型。

文件事件处理器有四个组成部分：套接字、I/O 多路复用程序、文件事件分派器、事件处理器。

img

# 时间事件

时间事件又分为：

  • 定时事件：是让一段程序在指定的时间之内执行一次；
  • 周期性事件：是让一段程序每隔指定时间就执行一次。

Redis 将所有时间事件都放在一个无序链表中，每当时间事件执行器运行时，通过遍历整个链表查找出已到达的时间事件，并调用响应的事件处理器。

# 事件的调度与执行

服务器需要不断监听文件事件的套接字才能得到待处理的文件事件，但是不能一直监听，否则时间事件无法在规定的时间内执行，因此监听时间应该根据距离现在最近的时间事件来决定。

事件调度与执行由 aeProcessEvents 函数负责，伪代码如下：

def aeProcessEvents():
+
+    ## 获取到达时间离当前时间最接近的时间事件
+    time_event = aeSearchNearestTimer()
+
+    ## 计算最接近的时间事件距离到达还有多少毫秒
+    remaind_ms = time_event.when - unix_ts_now()
+
+    ## 如果事件已到达，那么 remaind_ms 的值可能为负数，将它设为 0
+    if remaind_ms < 0:
+        remaind_ms = 0
+
+    ## 根据 remaind_ms 的值，创建 timeval
+    timeval = create_timeval_with_ms(remaind_ms)
+
+    ## 阻塞并等待文件事件产生，最大阻塞时间由传入的 timeval 决定
+    aeApiPoll(timeval)
+
+    ## 处理所有已产生的文件事件
+    procesFileEvents()
+
+    ## 处理所有已到达的时间事件
+    processTimeEvents()
+

将 aeProcessEvents 函数置于一个循环里面，加上初始化和清理函数，就构成了 Redis 服务器的主函数，伪代码如下：

def main():
+
+    ## 初始化服务器
+    init_server()
+
+    ## 一直处理事件，直到服务器关闭为止
+    while server_is_not_shutdown():
+        aeProcessEvents()
+
+    ## 服务器关闭，执行清理操作
+    clean_server()
+

从事件处理的角度来看，服务器运行流程如下：

# 六、Redis 事务

Redis 提供的不是严格的事务，Redis 只保证串行执行命令，并且能保证全部执行，但是执行命令失败时并不会回滚，而是会继续执行下去。

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务相关的命令。

事务可以一次执行多个命令， 并且有以下两个重要的保证：

  • 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
  • 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

# MULTI

MULTI (opens new window) 命令用于开启一个事务，它总是返回 OK 。

MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 EXEC 命令被调用时， 所有队列中的命令才会被执行。

以下是一个事务例子， 它原子地增加了 foo 和 bar 两个键的值：

> MULTI
+OK
+> INCR foo
+QUEUED
+> INCR bar
+QUEUED
+> EXEC
+1) (integer) 1
+2) (integer) 1
+

# EXEC

EXEC (opens new window) 命令负责触发并执行事务中的所有命令。

  • 如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。
  • 另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都会被执行。

# DISCARD

当执行 DISCARD (opens new window) 命令时， 事务会被放弃， 事务队列会被清空， 并且客户端会从事务状态中退出。

示例：

> SET foo 1
+OK
+> MULTI
+OK
+> INCR foo
+QUEUED
+> DISCARD
+OK
+> GET foo
+"1"
+

# WATCH

WATCH (opens new window) 命令可以为 Redis 事务提供 check-and-set （CAS）行为。

被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回 nil-reply 来表示事务已经失败。

WATCH mykey
+val = GET mykey
+val = val + 1
+MULTI
+SET mykey $val
+EXEC
+

使用上面的代码， 如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。

这种形式的锁被称作乐观锁， 它是一种非常强大的锁机制。 并且因为大多数情况下， 不同的客户端会访问不同的键， 碰撞的情况一般都很少， 所以通常并不需要进行重试。

WATCH 使得 EXEC 命令需要有条件地执行：事务只能在所有被监视键都没有被修改的前提下执行，如果这个前提不能满足的话，事务就不会被执行。

WATCH 命令可以被调用多次。对键的监视从 WATCH 执行之后开始生效，直到调用 EXEC 为止。

用户还可以在单个 WATCH 命令中监视任意多个键，例如：

redis> WATCH key1 key2 key3
+OK
+

# 取消 WATCH 的场景

当 EXEC 被调用时， 不管事务是否成功执行， 对所有键的监视都会被取消。

另外， 当客户端断开连接时， 该客户端对键的监视也会被取消。

使用无参数的 UNWATCH 命令可以手动取消对所有键的监视。 对于一些需要改动多个键的事务， 有时候程序需要同时对多个键进行加锁， 然后检查这些键的当前值是否符合程序的要求。 当值达不到要求时， 就可以使用 UNWATCH 命令来取消目前对键的监视， 中途放弃这个事务， 并等待事务的下次尝试。

# 使用 WATCH 创建原子操作

WATCH 可以用于创建 Redis 没有内置的原子操作。

举个例子，以下代码实现了原创的 ZPOP 命令，它可以原子地弹出有序集合中分值（score）最小的元素：

WATCH zset
+element = ZRANGE zset 0 0
+MULTI
+ZREM zset element
+EXEC
+

# Rollback

Redis 不支持回滚。Redis 不支持回滚的理由：

  • Redis 命令只会因为错误的语法而失败，或是命令用在了错误类型的键上面。
  • 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

# 七、Redis 管道

Redis 是一种基于 C/S 模型以及请求/响应协议的 TCP 服务。Redis 支持管道技术。管道技术允许请求以异步方式发送，即旧请求的应答还未返回的情况下，允许发送新请求。这种方式可以大大提高传输效率。

在需要批量执行 Redis 命令时，如果一条一条执行，显然很低效。为了减少通信次数并降低延迟，可以使用 Redis 管道功能。Redis 的管道（pipeline）功能没有提供命令行支持，但是在各种语言版本的客户端中都有相应的实现。

以 Jedis 为例：

Pipeline pipe = conn.pipelined();
+pipe.multi();
+pipe.hset("login:", token, user);
+pipe.zadd("recent:", timestamp, token);
+if (item != null) {
+    pipe.zadd("viewed:" + token, timestamp, item);
+    pipe.zremrangeByRank("viewed:" + token, 0, -26);
+    pipe.zincrby("viewed:", -1, item);
+}
+pipe.exec();
+

🔔 注意：使用管道发送命令时，Redis Server 会将部分请求放到缓存队列中（占用内存），执行完毕后一次性发送结果。如果需要发送大量的命令，会占用大量的内存，因此应该按照合理数量分批次的处理。

# 八、Redis 发布与订阅

Redis 提供了 5 个发布与订阅命令：

命令 描述
SUBSCRIBE SUBSCRIBE channel [channel ...]—订阅指定频道。
UNSUBSCRIBE UNSUBSCRIBE [channel [channel ...]]—取消订阅指定频道。
PUBLISH PUBLISH channel message—发送信息到指定的频道。
PSUBSCRIBE PSUBSCRIBE pattern [pattern ...]—订阅符合指定模式的频道。
PUNSUBSCRIBE PUNSUBSCRIBE [pattern [pattern ...]]—取消订阅符合指定模式的频道。

订阅者订阅了频道之后，发布者向频道发送字符串消息会被所有订阅者接收到。

某个客户端使用 SUBSCRIBE 订阅一个频道，其它客户端可以使用 PUBLISH 向这个频道发送消息。

发布与订阅模式和观察者模式有以下不同：

  • 观察者模式中，观察者和主题都知道对方的存在；而在发布与订阅模式中，发布者与订阅者不知道对方的存在，它们之间通过频道进行通信。
  • 观察者模式是同步的，当事件触发时，主题会去调用观察者的方法；而发布与订阅模式是异步的；

分割线以下为 Redis 集群功能特性

# 九、Redis 复制

关系型数据库通常会使用一个主服务器向多个从服务器发送更新，并使用从服务器来处理所有读请求，Redis 也采用了同样的方式来实现复制特性。

# 旧版复制

Redis 2.8 版本以前的复制功能基于 SYNC 命令实现。

Redis 的复制功能分为同步（sync）和命令传播（command propagate）两个操作：

  • 同步（sync） - 用于将从服务器的数据库状态更新至主服务器当前的数据库状态。
  • 命令传播（command propagate） - 当主服务器的数据库状态被修改，导致主从数据库状态不一致时，让主从服务器的数据库重新回到一致状态。

这种方式存在缺陷：不能高效处理断线重连后的复制情况。

# 新版复制

Redis 2.8 版本以后的复制功能基于 PSYNC 命令实现。PSYNC 命令具有完整重同步和部分重同步两种模式。

  • 完整重同步（full resychronization） - 用于初次复制。执行步骤与 SYNC 命令基本一致。
  • 部分重同步（partial resychronization） - 用于断线后重复制。如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只需接收并执行这些写命令，即可将主从服务器的数据库状态保持一致。

# 部分重同步

部分重同步有三个组成部分：

  • 主从服务器的复制偏移量（replication offset）
  • 主服务器的复制积压缓冲区（replication backlog）
  • 服务器的运行 ID

# PSYNC 命令

从服务器向要复制的主服务器发送 PSYNC <runid> <offset> 命令

  • 假如主从服务器的 master run id 相同，并且指定的偏移量（offset）在内存缓冲区中还有效，复制就会从上次中断的点开始继续。
  • 如果其中一个条件不满足，就会进行完全重新同步。

# 心跳检测

主服务器通过向从服务传播命令来更新从服务器状态，保持主从数据一致。

从服务器通过向主服务器发送命令 REPLCONF ACK <replication_offset> 来进行心跳检测，以及命令丢失检测。

💡 更详细的特性及原理说明请参考：Redis 复制

# 十、Redis 哨兵

Sentinel（哨兵）可以监听主服务器，并在主服务器进入下线状态时，自动从从服务器中选举出新的主服务器。

💡 更详细的特性及原理说明请参考：Redis 哨兵

# 十一、Redis 集群

分片是将数据划分为多个部分的方法，可以将数据存储到多台机器里面，也可以从多台机器里面获取数据，这种方法在解决某些问题时可以获得线性级别的性能提升。

假设有 4 个 Reids 实例 R0，R1，R2，R3，还有很多表示用户的键 user:1，user:2，... 等等，有不同的方式来选择一个指定的键存储在哪个实例中。最简单的方式是范围分片，例如用户 id 从 0~1000 的存储到实例 R0 中，用户 id 从 1001~2000 的存储到实例 R1 中，等等。但是这样需要维护一张映射范围表，维护操作代价很高。还有一种方式是哈希分片，使用 CRC32 哈希函数将键转换为一个数字，再对实例数量求模就能知道应该存储的实例。

主要有三种分片方式：

  • 客户端分片：客户端使用一致性哈希等算法决定键应当分布到哪个节点。
  • 代理分片：将客户端请求发送到代理上，由代理转发请求到正确的节点上。
  • 服务器分片：Redis Cluster（官方的 Redis 集群解决方案）。

# 十二、Redis Client

Redis 社区中有多种编程语言的客户端，可以在这里查找合适的客户端：Redis 官方罗列的客户端清单 (opens new window)

redis 官方推荐的 Java Redis Client：

# 扩展阅读

💡 Redis 常用于分布式缓存，有关缓存的特性和原理请参考：缓存基本原理 (opens new window)

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#KV数据库#Redis
上次更新: 2023/06/29, 22:27:04
Redis 面试总结
Redis 数据类型和应用

+ ← + Redis 数据类型和应用→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/98c3a5/index.html b/pages/98c3a5/index.html new file mode 100644 index 00000000..ff3ebd52 --- /dev/null +++ b/pages/98c3a5/index.html @@ -0,0 +1,71 @@ + + + + + + Elasticsearch 快速入门 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-16
目录

Elasticsearch 快速入门

# Elasticsearch 快速入门

Elasticsearch (opens new window) 是一个分布式、RESTful 风格的搜索和数据分析引擎，能够解决不断涌现出的各种用例。 作为 Elastic Stack 的核心，它集中存储您的数据，帮助您发现意料之中以及意料之外的情况。

Elasticsearch (opens new window) 基于搜索库 Lucene (opens new window) 开发。ElasticSearch 隐藏了 Lucene 的复杂性，提供了简单易用的 REST API / Java API 接口（另外还有其他语言的 API 接口）。

以下简称 ES。

# Elasticsearch 简介

# 什么是 Elasticsearch

Elasticsearch (opens new window) 是一个分布式、RESTful 风格的搜索和数据分析引擎，能够解决不断涌现出的各种用例。 作为 Elastic Stack 的核心，它集中存储您的数据，帮助您发现意料之中以及意料之外的情况。

Elasticsearch (opens new window) 基于搜索库 Lucene (opens new window) 开发。ElasticSearch 隐藏了 Lucene 的复杂性，提供了简单易用的 REST API / Java API 接口（另外还有其他语言的 API 接口）。

ElasticSearch 可以视为一个文档存储，它将复杂数据结构序列化为 JSON 存储。

ElasticSearch 是近乎于实时的全文搜素，这是指：

  • 从写入数据到数据可以被搜索，存在较小的延迟（大概是 1s）
  • 基于 ES 执行搜索和分析可以达到秒级

# 核心概念

index -> type -> mapping -> document -> field
+

# Cluster

集群包含多个节点，每个节点属于哪个集群都是通过一个配置来决定的，对于中小型应用来说，刚开始一个集群就一个节点很正常。

# Node

Node 是集群中的一个节点，节点也有一个名称，默认是随机分配的。默认节点会去加入一个名称为 elasticsearch 的集群。如果直接启动一堆节点，那么它们会自动组成一个 elasticsearch 集群，当然一个节点也可以组成 elasticsearch 集群。

# Index

可以认为是文档（document）的优化集合。

ES 会为所有字段建立索引，经过处理后写入一个反向索引（Inverted Index）。查找数据的时候，直接查找该索引。

所以，ES 数据管理的顶层单位就叫做 Index（索引）。它是单个数据库的同义词。每个 Index （即数据库）的名字必须是小写。

# Type

每个索引里可以有一个或者多个类型（type）。类型（type） 是 index 的一个逻辑分类。

不同的 Type 应该有相似的结构（schema），举例来说，id字段不能在这个组是字符串，在另一个组是数值。这是与关系型数据库的表的一个区别 (opens new window)。性质完全不同的数据（比如products和logs）应该存成两个 Index，而不是一个 Index 里面的两个 Type（虽然可以做到）。

注意：根据规划 (opens new window)，Elastic 6.x 版只允许每个 Index 包含一个 Type，7.x 版将会彻底移除 Type。

# Document

Index 里面单条的记录称为 Document（文档）。许多条 Document 构成了一个 Index。

每个 文档（document） 都是字段（field）的集合。

Document 使用 JSON 格式表示，下面是一个例子。

{
+"user": "张三",
+"title": "工程师",
+"desc": "数据库管理"
+}
+

同一个 Index 里面的 Document，不要求有相同的结构（scheme），但是最好保持相同，这样有利于提高搜索效率。

# Field

字段（field） 是包含数据的键值对。

默认情况下，Elasticsearch 对每个字段中的所有数据建立索引，并且每个索引字段都具有专用的优化数据结构。

# Shard

当单台机器不足以存储大量数据时，Elasticsearch 可以将一个索引中的数据切分为多个 分片（shard） 。 分片（shard） 分布在多台服务器上存储。有了 shard 就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。每个 shard 都是一个 lucene index。

# Replica

任何一个服务器随时可能故障或宕机，此时 shard 可能就会丢失，因此可以为每个 shard 创建多个 副本（replica）。replica 可以在 shard 故障时提供备用服务，保证数据不丢失，多个 replica 还可以提升搜索操作的吞吐量和性能。primary shard（建立索引时一次设置，不能修改，默认 5 个），replica shard（随时修改数量，默认 1 个），默认每个索引 10 个 shard，5 个 primary shard，5 个 replica shard，最小的高可用配置，是 2 台服务器。

# ES 核心概念 vs. DB 核心概念

ES DB
index 数据库
type 数据表
docuemnt 一行数据

# ElasticSearch 基本原理

# ES 写数据过程

  • 客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node（协调节点）。
  • coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。
  • 实际的 node 上的 primary shard 处理请求，然后将数据同步到 replica node。
  • coordinating node 如果发现 primary node 和所有 replica node 都搞定之后，就返回响应结果给客户端。

img

# ES 读数据过程

可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。

  • 客户端发送请求到任意一个 node，成为 coordinate node。
  • coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin 轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。
  • 接收请求的 node 返回 document 给 coordinate node。
  • coordinate node 返回 document 给客户端。

# es 搜索数据过程

es 最强大的是做全文检索，就是比如你有三条数据：

java真好玩儿啊
+java好难学啊
+j2ee特别牛
+

你根据 java 关键词来搜索，将包含 java 的 document 给搜索出来。es 就会给你返回：java 真好玩儿啊，java 好难学啊。

  • 客户端发送请求到一个 coordinate node 。
  • 协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard ，都可以。
  • query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id ）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。
  • fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

写请求是写入 primary shard，然后同步给所有的 replica shard；读请求可以从 primary shard 或 replica shard 读取，采用的是随机轮询算法。

# 写数据底层原理

es-write-detail (opens new window)

先写入内存 buffer，在 buffer 里的时候数据是搜索不到的；同时将数据写入 translog 日志文件。

如果 buffer 快满了，或者到一定时间，就会将内存 buffer 数据 refresh 到一个新的 segment file 中，但是此时数据不是直接进入 segment file 磁盘文件，而是先进入 os cache 。这个过程就是 refresh。

每隔 1 秒钟，es 将 buffer 中的数据写入一个新的 segment file，每秒钟会产生一个新的磁盘文件 segment file，这个 segment file 中就存储最近 1 秒内 buffer 中写入的数据。

但是如果 buffer 里面此时没有数据，那当然不会执行 refresh 操作，如果 buffer 里面有数据，默认 1 秒钟执行一次 refresh 操作，刷入一个新的 segment file 中。

操作系统里面，磁盘文件其实都有一个东西，叫做 os cache，即操作系统缓存，就是说数据写入磁盘文件之前，会先进入 os cache，先进入操作系统级别的一个内存缓存中去。只要 buffer 中的数据被 refresh 操作刷入 os cache中，这个数据就可以被搜索到了。

为什么叫 es 是准实时的？ NRT，全称 near real-time。默认是每隔 1 秒 refresh 一次的，所以 es 是准实时的，因为写入的数据 1 秒之后才能被看到。可以通过 es 的 restful api 或者 java api，手动执行一次 refresh 操作，就是手动将 buffer 中的数据刷入 os cache中，让数据立马就可以被搜索到。只要数据被输入 os cache 中，buffer 就会被清空了，因为不需要保留 buffer 了，数据在 translog 里面已经持久化到磁盘去一份了。

重复上面的步骤，新的数据不断进入 buffer 和 translog，不断将 buffer 数据写入一个又一个新的 segment file 中去，每次 refresh 完 buffer 清空，translog 保留。随着这个过程推进，translog 会变得越来越大。当 translog 达到一定长度的时候，就会触发 commit 操作。

commit 操作发生第一步，就是将 buffer 中现有数据 refresh 到 os cache 中去，清空 buffer。然后，将一个 commit point 写入磁盘文件，里面标识着这个 commit point 对应的所有 segment file，同时强行将 os cache 中目前所有的数据都 fsync 到磁盘文件中去。最后清空 现有 translog 日志文件，重启一个 translog，此时 commit 操作完成。

这个 commit 操作叫做 flush。默认 30 分钟自动执行一次 flush，但如果 translog 过大，也会触发 flush。flush 操作就对应着 commit 的全过程，我们可以通过 es api，手动执行 flush 操作，手动将 os cache 中的数据 fsync 强刷到磁盘上去。

translog 日志文件的作用是什么？你执行 commit 操作之前，数据要么是停留在 buffer 中，要么是停留在 os cache 中，无论是 buffer 还是 os cache 都是内存，一旦这台机器死了，内存中的数据就全丢了。所以需要将数据对应的操作写入一个专门的日志文件 translog 中，一旦此时机器宕机，再次重启的时候，es 会自动读取 translog 日志文件中的数据，恢复到内存 buffer 和 os cache 中去。

translog 其实也是先写入 os cache 的，默认每隔 5 秒刷一次到磁盘中去，所以默认情况下，可能有 5 秒的数据会仅仅停留在 buffer 或者 translog 文件的 os cache 中，如果此时机器挂了，会丢失 5 秒钟的数据。但是这样性能比较好，最多丢 5 秒的数据。也可以将 translog 设置成每次写操作必须是直接 fsync 到磁盘，但是性能会差很多。

实际上你在这里，如果面试官没有问你 es 丢数据的问题，你可以在这里给面试官炫一把，你说，其实 es 第一是准实时的，数据写入 1 秒后可以搜索到；可能会丢失数据的。有 5 秒的数据，停留在 buffer、translog os cache、segment file os cache 中，而不在磁盘上，此时如果宕机，会导致 5 秒的数据丢失。

总结一下，数据先写入内存 buffer，然后每隔 1s，将数据 refresh 到 os cache，到了 os cache 数据就能被搜索到（所以我们才说 es 从写入到能被搜索到，中间有 1s 的延迟）。每隔 5s，将数据写入 translog 文件（这样如果机器宕机，内存数据全没，最多会有 5s 的数据丢失），translog 大到一定程度，或者默认每隔 30mins，会触发 commit 操作，将缓冲区的数据都 flush 到 segment file 磁盘文件中。

数据写入 segment file 之后，同时就建立好了倒排索引。

# 删除/更新数据底层原理

如果是删除操作，commit 的时候会生成一个 .del 文件，里面将某个 doc 标识为 deleted 状态，那么搜索的时候根据 .del 文件就知道这个 doc 是否被删除了。

如果是更新操作，就是将原来的 doc 标识为 deleted 状态，然后新写入一条数据。

buffer 每 refresh 一次，就会产生一个 segment file，所以默认情况下是 1 秒钟一个 segment file，这样下来 segment file 会越来越多，此时会定期执行 merge。每次 merge 的时候，会将多个 segment file 合并成一个，同时这里会将标识为 deleted 的 doc 给物理删除掉，然后将新的 segment file 写入磁盘，这里会写一个 commit point，标识所有新的 segment file，然后打开 segment file 供搜索使用，同时删除旧的 segment file。

# 底层 lucene

简单来说，lucene 就是一个 jar 包，里面包含了封装好的各种建立倒排索引的算法代码。我们用 Java 开发的时候，引入 lucene jar，然后基于 lucene 的 api 去开发就可以了。

通过 lucene，我们可以将已有的数据建立索引，lucene 会在本地磁盘上面，给我们组织索引的数据结构。

# 倒排索引

在搜索引擎中，每个文档都有一个对应的文档 ID，文档内容被表示为一系列关键词的集合。例如，文档 1 经过分词，提取了 20 个关键词，每个关键词都会记录它在文档中出现的次数和出现位置。

那么，倒排索引就是关键词到文档 ID 的映射，每个关键词都对应着一系列的文件，这些文件中都出现了关键词。

举个栗子。

有以下文档：

DocId Doc
1 谷歌地图之父跳槽 Facebook
2 谷歌地图之父加盟 Facebook
3 谷歌地图创始人拉斯离开谷歌加盟 Facebook
4 谷歌地图之父跳槽 Facebook 与 Wave 项目取消有关
5 谷歌地图之父拉斯加盟社交网站 Facebook

对文档进行分词之后，得到以下倒排索引。

WordId Word DocIds
1 谷歌 1,2,3,4,5
2 地图 1,2,3,4,5
3 之父 1,2,4,5
4 跳槽 1,4
5 Facebook 1,2,3,4,5
6 加盟 2,3,5
7 创始人 3
8 拉斯 3,5
9 离开 3
10 与 4
.. .. ..

另外，实用的倒排索引还可以记录更多的信息，比如文档频率信息，表示在文档集合中有多少个文档包含某个单词。

那么，有了倒排索引，搜索引擎可以很方便地响应用户的查询。比如用户输入查询 Facebook，搜索系统查找倒排索引，从中读出包含这个单词的文档，这些文档就是提供给用户的搜索结果。

要注意倒排索引的两个重要细节：

  • 倒排索引中的所有词项对应一个或多个文档；
  • 倒排索引中的词项根据字典顺序升序排列

上面只是一个简单的栗子，并没有严格按照字典顺序升序排列。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch
上次更新: 2023/06/29, 22:27:04
Elasticsearch 面试总结
Elasticsearch 简介

+ ← + Elasticsearch 简介→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/9a2546/index.html b/pages/9a2546/index.html new file mode 100644 index 00000000..40ecfb88 --- /dev/null +++ b/pages/9a2546/index.html @@ -0,0 +1,149 @@ + + + + + + Elasticsearch 集群和分片 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-03-01
目录

Elasticsearch 集群和分片

# Elasticsearch 集群和分片

# 集群

# 空集群

如果我们启动了一个单独的节点，里面不包含任何的数据和索引，那我们的集群看起来就是一个包含空内容节点的集群。

Figure 1. 包含空内容节点的集群

包含空内容节点的集群

图 1：只有一个空节点的集群

一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。

作为用户，我们可以将请求发送到集群中的任何节点，包括主节点。 每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

# 集群健康

Elasticsearch 的集群监控信息中包含了许多的统计数据，其中最为重要的一项就是 集群健康 ， 它在 status 字段中展示为 green 、 yellow 或者 red 。

GET /_cluster/health
+

在一个不包含任何索引的空集群中，它将会有一个类似于如下所示的返回内容：

{
+  "cluster_name": "elasticsearch",
+  "status": "green",
+  "timed_out": false,
+  "number_of_nodes": 1,
+  "number_of_data_nodes": 1,
+  "active_primary_shards": 0,
+  "active_shards": 0,
+  "relocating_shards": 0,
+  "initializing_shards": 0,
+  "unassigned_shards": 0
+}
+

status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：

  • green：所有的主分片和副本分片都正常运行。
  • yellow：所有的主分片都正常运行，但不是所有的副本分片都正常运行。
  • red：有主分片没能正常运行。

# 添加索引

我们往 Elasticsearch 添加数据时需要用到 索引 —— 保存相关数据的地方。索引实际上是指向一个或者多个物理分片的逻辑命名空间 。

一个 分片 是一个底层的 工作单元 ，它仅保存了全部数据中的一部分。现在我们只需知道一个分片是一个 Lucene 的实例，以及它本身就是一个完整的搜索引擎。 我们的文档被存储和索引到分片内，但是应用程序是直接与索引而不是与分片进行交互。

Elasticsearch 是利用分片将数据分发到集群内各处的。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。 当你的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。

一个分片可以是 主 分片或者 副本 分片。 索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。

技术上来说，一个主分片最大能够存储 Integer.MAX_VALUE - 128 个文档，但是实际最大值还需要参考你的使用场景：包括你使用的硬件， 文档的大小和复杂程度，索引和查询文档的方式以及你期望的响应时长。

一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。

在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改。

让我们在包含一个空节点的集群内创建名为 blogs 的索引。 索引在默认情况下会被分配 5 个主分片， 但是为了演示目的，我们将分配 3 个主分片和一份副本（每个主分片拥有一个副本分片）：

PUT /blogs
+{
+   "settings" : {
+      "number_of_shards" : 3,
+      "number_of_replicas" : 1
+   }
+}
+

我们的集群现在是 拥有一个索引的单节点集群。所有 3 个主分片都被分配在 Node 1 。

Figure 2. 拥有一个索引的单节点集群

拥有一个索引的单节点集群

如果我们现在查看集群健康，我们将看到如下内容：

{
+  "cluster_name": "elasticsearch",
+  "status": "yellow",
+  "timed_out": false,
+  "number_of_nodes": 1,
+  "number_of_data_nodes": 1,
+  "active_primary_shards": 3,
+  "active_shards": 3,
+  "relocating_shards": 0,
+  "initializing_shards": 0,
+  "unassigned_shards": 3,
+  "delayed_unassigned_shards": 0,
+  "number_of_pending_tasks": 0,
+  "number_of_in_flight_fetch": 0,
+  "task_max_waiting_in_queue_millis": 0,
+  "active_shards_percent_as_number": 50
+}
+
  • 集群 status 值为 yellow
  • 没有被分配到任何节点的副本数

集群的健康状况为 yellow 则表示全部 主 分片都正常运行（集群可以正常服务所有请求），但是 副本 分片没有全部处在正常状态。 实际上，所有 3 个副本分片都是 unassigned —— 它们都没有被分配到任何节点。 在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，我们也将丢失该节点上的所有副本数据。

当前我们的集群是正常运行的，但是在硬件故障时有丢失数据的风险。

# 添加故障转移

当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。 幸运的是，我们只需再启动一个节点即可防止数据丢失。

为了测试第二个节点启动后的情况，你可以在同一个目录内，完全依照启动第一个节点的方式来启动一个新节点（参考安装并运行 Elasticsearch）。多个节点可以共享同一个目录。

当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。 但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。

如果启动了第二个节点，我们的集群将会拥有两个节点的集群——所有主分片和副本分片都已被分配。

Figure 3. 拥有两个节点的集群——所有主分片和副本分片都已被分配

拥有两个节点的集群

当第二个节点加入到集群后，3 个 副本分片 将会分配到这个节点上——每个主分片对应一个副本分片。 这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。

所有新近被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获得文档。

cluster-health 现在展示的状态为 green ，这表示所有 6 个分片（包括 3 个主分片和 3 个副本分片）都在正常运行。

{
+  "cluster_name": "elasticsearch",
+  "status": "green",
+  "timed_out": false,
+  "number_of_nodes": 2,
+  "number_of_data_nodes": 2,
+  "active_primary_shards": 3,
+  "active_shards": 6,
+  "relocating_shards": 0,
+  "initializing_shards": 0,
+  "unassigned_shards": 0,
+  "delayed_unassigned_shards": 0,
+  "number_of_pending_tasks": 0,
+  "number_of_in_flight_fetch": 0,
+  "task_max_waiting_in_queue_millis": 0,
+  "active_shards_percent_as_number": 100
+}
+
  • 集群 status 值为 green

我们的集群现在不仅仅是正常运行的，并且还处于 始终可用 的状态。

# 水平扩容

怎样为我们的正在增长中的应用程序按需扩容呢？ 当启动了第三个节点，我们的集群将拥有三个节点的集群——为了分散负载而对分片进行重新分配。

Figure 4. 拥有三个节点的集群——为了分散负载而对分片进行重新分配

拥有三个节点的集群

Node 1 和 Node 2 上各有一个分片被迁移到了新的 Node 3 节点，现在每个节点上都拥有 2 个分片，而不是之前的 3 个。 这表示每个节点的硬件资源（CPU, RAM, I/O）将被更少的分片所共享，每个分片的性能将会得到提升。

分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。 我们这个拥有 6 个分片（3 个主分片和 3 个副本分片）的索引可以最大扩容到 6 个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源。

# 更多的扩容

但是如果我们想要扩容超过 6 个节点怎么办呢？

主分片的数目在索引创建时就已经确定了下来。实际上，这个数目定义了这个索引能够 存储 的最大数据量。（实际大小取决于你的数据、硬件和使用场景。） 但是，读操作——搜索和返回数据——可以同时被主分片 或 副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量。

在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群。让我们把副本数从默认的 1 增加到 2 ：

PUT /blogs/_settings
+{
+   "number_of_replicas" : 2
+}
+

blogs 索引现在拥有 9 个分片：3 个主分片和 6 个副本分片。 这意味着我们可以将集群扩容到 9 个节点，每个节点上一个分片。相比原来 3 个节点时，集群搜索性能可以提升 3 倍。

Figure 5. 将参数 number_of_replicas 调大到 2

拥有2份副本分片3个节点的集群

当然，如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能，因为每个分片从节点上获得的资源会变少。 你需要增加更多的硬件资源来提升吞吐量。

但是更多的副本分片数提高了数据冗余量：按照上面的节点配置，我们可以在失去 2 个节点的情况下不丢失任何数据。

# 应对故障

我们之前说过 Elasticsearch 可以应对节点故障，接下来让我们尝试下这个功能。 如果我们关闭第一个节点，这时集群的状态为关闭了一个节点后的集群。

Figure 6. 关闭了一个节点后的集群

关闭了一个节点后的集群

我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： Node 2 。

在我们关闭 Node 1 的同时也失去了主分片 1 和 2 ，并且在缺失主分片的时候索引也不能正常工作。 如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。

幸运的是，在其它节点上存在着这两个主分片的完整副本， 所以新的主节点立即将这些分片在 Node 2 和 Node 3 上对应的副本分片提升为主分片， 此时集群的状态将会为 yellow 。 这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。

为什么我们集群状态是 yellow 而不是 green 呢？ 虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应 2 份副本分片，而此时只存在一份副本分片。 所以集群不能为 green 的状态，不过我们不必过于担心：如果我们同样关闭了 Node 2 ，我们的程序 依然 可以保持在不丢任何数据的情况下运行，因为 Node 3 为每一个分片都保留着一份副本。

如果我们重新启动 Node 1 ，集群可以将缺失的副本分片再次进行分配，那么集群的状态也将如 Figure 5. 将参数 number_of_replicas 调大到 2 所示。 如果 Node 1 依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件。

到目前为止，你应该对分片如何使得 Elasticsearch 进行水平扩容以及数据保障等知识有了一定了解。 接下来我们将讲述关于分片生命周期的更多细节。

# 分片

  • 为什么搜索是 近 实时的？
  • 为什么文档的 CRUD (创建-读取-更新-删除) 操作是 实时 的?
  • Elasticsearch 是怎样保证更新被持久化在断电时也不丢失数据?
  • 为什么删除文档不会立刻释放空间？
  • refresh, flush, 和 optimize API 都做了什么, 你什么情况下应该使用他们？

# 使文本可被搜索

必须解决的第一个挑战是如何使文本可被搜索。 传统的数据库每个字段存储单个值，但这对全文检索并不够。文本字段中的每个单词需要被搜索，对数据库意味着需要单个字段有索引多值(这里指单词)的能力。

最好的支持 一个字段多个值 需求的数据结构是我们在 倒排索引 (opens new window) 章节中介绍过的 倒排索引 。 倒排索引包含一个有序列表，列表包含所有文档出现过的不重复个体，或称为 词项 ，对于每一个词项，包含了它所有曾出现过文档的列表。

Term  | Doc 1 | Doc 2 | Doc 3 | ...
+------------------------------------
+brown |   X   |       |  X    | ...
+fox   |   X   |   X   |  X    | ...
+quick |   X   |   X   |       | ...
+the   |   X   |       |  X    | ...
+

当讨论倒排索引时，我们会谈到 文档 标引，因为历史原因，倒排索引被用来对整个非结构化文本文档进行标引。 Elasticsearch 中的 文档 是有字段和值的结构化 JSON 文档。事实上，在 JSON 文档中， 每个被索引的字段都有自己的倒排索引。

这个倒排索引相比特定词项出现过的文档列表，会包含更多其它信息。它会保存每一个词项出现过的文档总数， 在对应的文档中一个具体词项出现的总次数，词项在文档中的顺序，每个文档的长度，所有文档的平均长度，等等。这些统计信息允许 Elasticsearch 决定哪些词比其它词更重要，哪些文档比其它文档更重要，这些内容在 什么是相关性? (opens new window) 中有描述。

为了能够实现预期功能，倒排索引需要知道集合中的 所有 文档，这是需要认识到的关键问题。

早期的全文检索会为整个文档集合建立一个很大的倒排索引并将其写入到磁盘。 一旦新的索引就绪，旧的就会被其替换，这样最近的变化便可以被检索到。

# 不变性

倒排索引被写入磁盘后是 不可改变 的:它永远不会修改。 不变性有重要的价值：

  • 不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
  • 一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
  • 其它缓存(像 filter 缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
  • 写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。

当然，一个不变的索引也有不好的地方。主要事实是它是不可变的! 你不能修改它。如果你需要让一个新的文档 可被搜索，你需要重建整个索引。这要么对一个索引所能包含的数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。

# 动态更新索引

下一个需要被解决的问题是怎样在保留不变性的前提下实现倒排索引的更新？答案是: 用更多的索引。

通过增加新的补充索引来反映新近的修改，而不是直接重写整个倒排索引。每一个倒排索引都会被轮流查询到—从最早的开始—查询完后再对结果进行合并。

Elasticsearch 基于 Lucene, 这个 java 库引入了 按段搜索 的概念。 每一 段 本身都是一个倒排索引， 但 索引 在 Lucene 中除表示所有 段 的集合外， 还增加了 提交点 的概念 — 一个列出了所有已知段的文件，就像在 Figure 16, “一个 Lucene 索引包含一个提交点和三个段” 中描绘的那样。 如 Figure 17, “一个在内存缓存中包含新文档的 Lucene 索引” 所示，新的文档首先被添加到内存索引缓存中，然后写入到一个基于磁盘的段，如 Figure 18, “在一次提交后，一个新的段被添加到提交点而且缓存被清空。” 所示。

Figure 16. 一个 Lucene 索引包含一个提交点和三个段

A Lucene index with a commit point and three segments

被混淆的概念是，一个 Lucene 索引 我们在 Elasticsearch 称作 分片 。 一个 Elasticsearch 索引 是分片的集合。 当 Elasticsearch 在索引中搜索的时候， 他发送查询到每一个属于索引的分片(Lucene 索引)，然后像 执行分布式检索 (opens new window) 提到的那样，合并每个分片的结果到一个全局的结果集。

逐段搜索会以如下流程进行工作：

  1. 新文档被收集到内存索引缓存， 见 Figure 17, “一个在内存缓存中包含新文档的 Lucene 索引” 。
  2. 不时地, 缓存被 提交 ： +
    • 一个新的段—一个追加的倒排索引—被写入磁盘。
    • 一个新的包含新段名字的 提交点 被写入磁盘。
    • 磁盘进行 同步 — 所有在文件系统缓存中等待的写入都刷新到磁盘，以确保它们被写入物理文件。
  3. 新的段被开启，让它包含的文档可见以被搜索。
  4. 内存缓存被清空，等待接收新的文档。

Figure 17. 一个在内存缓存中包含新文档的 Lucene 索引

A Lucene index with new documents in the in-memory buffer, ready to commit

Figure 18. 在一次提交后，一个新的段被添加到提交点而且缓存被清空。

After a commit, a new segment is added to the index and the buffer is cleared

当一个查询被触发，所有已知的段按顺序被查询。词项统计会对所有段的结果进行聚合，以保证每个词和每个文档的关联都被准确计算。 这种方式可以用相对较低的成本将新文档添加到索引。

# 删除和更新

段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新。 取而代之的是，每个提交点会包含一个 .del 文件，文件中会列出这些被删除文档的段信息。

当一个文档被 “删除” 时，它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。

文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。

在 段合并 (opens new window) , 我们展示了一个被删除的文档是怎样被文件系统移除的。

# 近实时搜索

随着按段（per-segment）搜索的发展，一个新的文档从索引到可被搜索的延迟显著降低了。新文档在几分钟之内即可被检索，但这样还是不够快。

磁盘在这里成为了瓶颈。提交（Commiting）一个新的段到磁盘需要一个 fsync (opens new window) 来确保段被物理性地写入磁盘，这样在断电的时候就不会丢失数据。 但是 fsync 操作代价很大; 如果每次索引一个文档都去执行一次的话会造成很大的性能问题。

我们需要的是一个更轻量的方式来使一个文档可被搜索，这意味着 fsync 要从整个过程中被移除。

在 Elasticsearch 和磁盘之间是文件系统缓存。 像之前描述的一样， 在内存索引缓冲区（ Figure 19, “在内存缓冲区中包含了新文档的 Lucene 索引” (opens new window) ）中的文档会被写入到一个新的段中（ Figure 20, “缓冲区的内容已经被写入一个可被搜索的段中，但还没有进行提交” (opens new window) ）。 但是这里新段会被先写入到文件系统缓存—这一步代价会比较低，稍后再被刷新到磁盘—这一步代价比较高。不过只要文件已经在缓存中， 就可以像其它文件一样被打开和读取了。

Figure 19. 在内存缓冲区中包含了新文档的 Lucene 索引

A Lucene index with new documents in the in-memory buffer

Lucene 允许新段被写入和打开—使其包含的文档在未进行一次完整提交时便对搜索可见。 这种方式比进行一次提交代价要小得多，并且在不影响性能的前提下可以被频繁地执行。

Figure 20. 缓冲区的内容已经被写入一个可被搜索的段中，但还没有进行提交

The buffer contents have been written to a segment, which is searchable, but is not yet commited

# refresh API

在 Elasticsearch 中，写入和打开一个新段的轻量的过程叫做 refresh 。 默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是 近 实时搜索: 文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。

这些行为可能会对新用户造成困惑: 他们索引了一个文档然后尝试搜索它，但却没有搜到。这个问题的解决办法是用 refresh API 执行一次手动刷新:

POST /_refresh
+POST /blogs/_refresh
+

刷新（Refresh）所有的索引

只刷新（Refresh） blogs 索引

尽管刷新是比提交轻量很多的操作，它还是会有性能开销。当写测试的时候， 手动刷新很有用，但是不要在生产环境下每次索引一个文档都去手动刷新。 相反，你的应用需要意识到 Elasticsearch 的近实时的性质，并接受它的不足。

并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引大量的日志文件， 你可能想优化索引速度而不是近实时搜索， 可以通过设置 refresh_interval ， 降低每个索引的刷新频率：

PUT /my_logs
+{
+  "settings": {
+    "refresh_interval": "30s"
+  }
+}
+

每 30 秒刷新 my_logs 索引。

refresh_interval 可以在既存索引上进行动态更新。 在生产环境中，当你正在建立一个大的新索引时，可以先关闭自动刷新，待开始使用该索引时，再把它们调回来：

PUT /my_logs/_settings
+{ "refresh_interval": -1 }
+
+PUT /my_logs/_settings
+{ "refresh_interval": "1s" }
+

  • 关闭自动刷新。

  • 每秒自动刷新。

refresh_interval 需要一个 持续时间 值， 例如 1s （1 秒） 或 2m （2 分钟）。 一个绝对值 1 表示的是 1 毫秒 --无疑会使你的集群陷入瘫痪。

# 持久化变更

如果没有用 fsync 把数据从文件系统缓存刷（flush）到硬盘，我们不能保证数据在断电甚至是程序正常退出之后依然存在。为了保证 Elasticsearch 的可靠性，需要确保数据变化被持久化到磁盘。

在 动态更新索引 (opens new window)，我们说一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点。Elasticsearch 在启动或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片。

即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确保能从失败中恢复。但在两次提交之间发生变化的文档怎么办？我们也不希望丢失掉这些数据。

Elasticsearch 增加了一个 translog ，或者叫事务日志，在每一次对 Elasticsearch 进行操作时均进行了日志记录。通过 translog ，整个流程看起来是下面这样：

一个文档被索引之后，就会被添加到内存缓冲区，并且 追加到了 translog ，正如 Figure 21, “新的文档被添加到内存缓冲区并且被追加到了事务日志” (opens new window) 描述的一样。

Figure 21. 新的文档被添加到内存缓冲区并且被追加到了事务日志

New documents are added to the in-memory buffer and appended to the transaction log

刷新（refresh）使分片处于 Figure 22, “刷新（refresh）完成后, 缓存被清空但是事务日志不会” (opens new window) 描述的状态，分片每秒被刷新（refresh）一次：

  • 这些在内存缓冲区的文档被写入到一个新的段中，且没有进行 fsync 操作。
  • 这个段被打开，使其可被搜索。
  • 内存缓冲区被清空。

Figure 22. 刷新（refresh）完成后, 缓存被清空但是事务日志不会

After a refresh, the buffer is cleared but the transaction log is not

这个进程继续工作，更多的文档被添加到内存缓冲区和追加到事务日志（见 Figure 23, “事务日志不断积累文档” (opens new window) ）。

Figure 23. 事务日志不断积累文档

The transaction log keeps accumulating documents

  1. 每隔一段时间—例如 translog 变得越来越大—索引被刷新（flush）；一个新的 translog 被创建，并且一个全量提交被执行（见 Figure 24, “在刷新（flush）之后，段被全量提交，并且事务日志被清空” (opens new window) ）： +
    • 所有在内存缓冲区的文档都被写入一个新的段。
    • 缓冲区被清空。
    • 一个提交点被写入硬盘。
    • 文件系统缓存通过 fsync 被刷新（flush）。
    • 老的 translog 被删除。

translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时候， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。

translog 也被用来提供实时 CRUD 。当你试着通过 ID 查询、更新、删除一个文档，它会在尝试从相应的段中检索之前， 首先检查 translog 任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。

Figure 24. 在刷新（flush）之后，段被全量提交，并且事务日志被清空

After a flush, the segments are fully commited and the transaction log is cleared

# flush API

这个执行一个提交并且截断 translog 的行为在 Elasticsearch 被称作一次 flush 。 分片每 30 分钟被自动刷新（flush），或者在 translog 太大的时候也会刷新。请查看 translog 文档 (opens new window) 来设置，它可以用来 控制这些阈值：

flush API (opens new window) 可以被用来执行一个手工的刷新（flush）:

POST /blogs/_flush
+POST /_flush?wait_for_ongoing
+
  • 刷新（flush） blogs 索引。
  • 刷新（flush）所有的索引并且并且等待所有刷新在返回前完成。

你很少需要自己手动执行 flush 操作；通常情况下，自动刷新就足够了。

这就是说，在重启节点或关闭索引之前执行 flush (opens new window) 有益于你的索引。当 Elasticsearch 尝试恢复或重新打开一个索引， 它需要重放 translog 中所有的操作，所以如果日志越短，恢复越快。

translog 的目的是保证操作不会丢失。这引出了这个问题： Translog 有多安全？

在文件被 fsync 到磁盘前，被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被 fsync 刷新到硬盘， 或者在每次写请求完成之后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。最终， 基本上，这意味着在整个请求被 fsync 到主分片和复制分片的 translog 之前，你的客户端不会得到一个 200 OK 响应。

在每次请求后都执行一个 fsync 会带来一些性能损失，尽管实践表明这种损失相对较小（特别是 bulk 导入，它在一次请求中平摊了大量文档的开销）。

但是对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群，使用异步的 fsync 还是比较有益的。比如，写入的数据被缓存到内存中，再每 5 秒执行一次 fsync 。

这个行为可以通过设置 durability 参数为 async 来启用：

PUT /my_index/_settings
+{
+    "index.translog.durability": "async",
+    "index.translog.sync_interval": "5s"
+}
+

这个选项可以针对索引单独设置，并且可以动态进行修改。如果你决定使用异步 translog 的话，你需要 保证 在发生 crash 时，丢失掉 sync_interval 时间段的数据也无所谓。请在决定前知晓这个特性。

如果你不确定这个行为的后果，最好是使用默认的参数（ "index.translog.durability": "request" ）来避免数据丢失。

# 段合并

由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和 cpu 运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。

Elasticsearch 通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。

段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。

启动段合并不需要你做任何事。进行索引和搜索时会自动进行。这个流程像在 Figure 25, “两个提交了的段和一个未提交的段正在被合并到一个更大的段” (opens new window) 中提到的一样工作：

1、 当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用。

2、 合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中。这并不会中断索引和搜索。

Figure 25. 两个提交了的段和一个未提交的段正在被合并到一个更大的段

Two commited segments and one uncommited segment in the process of being merged into a bigger segment

Figure 26, “一旦合并结束，老的段被删除” (opens new window) 说明合并完成时的活动：

  • 新的段被刷新（flush）到了磁盘。 ** 写入一个包含新段且排除旧的和较小的段的新提交点。
  • 新的段被打开用来搜索。
  • 老的段被删除。

Figure 26. 一旦合并结束，老的段被删除

一旦合并结束，老的段被删除

合并大的段需要消耗大量的 I/O 和 CPU 资源，如果任其发展会影响搜索性能。Elasticsearch 在默认情况下会对合并流程进行资源限制，所以搜索仍然 有足够的资源很好地执行。

# optimize API

optimize API 大可看做是 强制合并 API。它会将一个分片强制合并到 max_num_segments 参数指定大小的段数目。 这样做的意图是减少段的数量（通常减少到一个），来提升搜索性能。

optimize API 不应该 被用在一个活跃的索引————一个正积极更新的索引。后台合并流程已经可以很好地完成工作。 optimizing 会阻碍这个进程。不要干扰它！

在特定情况下，使用 optimize API 颇有益处。例如在日志这种用例下，每天、每周、每月的日志被存储在一个索引中。 老的索引实质上是只读的；它们也并不太可能会发生变化。

在这种情况下，使用 optimize 优化老的索引，将每一个分片合并为一个单独的段就很有用了；这样既可以节省资源，也可以使搜索更加快速：

POST /logstash-2014-10/_optimize?max_num_segments=1
+

合并索引中的每个分片为一个单独的段

请注意，使用 optimize API 触发段合并的操作不会受到任何资源上的限制。这可能会消耗掉你节点上全部的 I/O 资源, 使其没有余裕来处理搜索请求，从而有可能使集群失去响应。 如果你想要对索引执行 optimize，你需要先使用分片分配（查看 迁移旧索引 (opens new window)）把索引移到一个安全的节点，再执行。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#集群#分片
上次更新: 2023/06/29, 22:27:04
ElasticSearch Java API 之 High Level REST Client
Elasticsearch 运维

+ ← + Elasticsearch 运维→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/9bb28f/index.html b/pages/9bb28f/index.html new file mode 100644 index 00000000..77ecd351 --- /dev/null +++ b/pages/9bb28f/index.html @@ -0,0 +1,120 @@ + + + + + + 关系型数据库面试 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-01-15
目录

关系型数据库面试

# 关系型数据库面试

# 索引和约束

# 什么是索引

索引是对数据库表中一或多个列的值进行排序的结构，是帮助数据库高效查询数据的数据结构。

# 索引的优缺点

✔ 索引的优点：

  • 索引大大减少了服务器需要扫描的数据量，从而加快检索速度。
  • 支持行级锁的数据库，如 InnoDB 会在访问行的时候加锁。使用索引可以减少访问的行数，从而减少锁的竞争，提高并发。
  • 索引可以帮助服务器避免排序和临时表。
  • 索引可以将随机 I/O 变为顺序 I/O。
  • 唯一索引可以确保每一行数据的唯一性，通过使用索引，可以在查询的过程中使用优化隐藏器，提高系统的性能。

❌ 索引的缺点：

  • 创建和维护索引要耗费时间，这会随着数据量的增加而增加。
  • 索引需要占用额外的物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立组合索引那么需要的空间就会更大。
  • 写操作（INSERT/UPDATE/DELETE）时很可能需要更新索引，导致数据库的写操作性能降低。

# 何时使用索引

索引能够轻易将查询性能提升几个数量级。

✔ 什么情况适用索引：

  • 表经常进行 SELECT 操作；
  • 表的数据量比较大；
  • 列名经常出现在 WHERE 或连接（JOIN）条件中

❌ 什么情况不适用索引：

  • 频繁写操作（ INSERT/UPDATE/DELETE ）- 需要更新索引空间；
  • 非常小的表 - 对于非常小的表，大部分情况下简单的全表扫描更高效。
  • 列名不经常出现在 WHERE 或连接（JOIN）条件中 - 索引就会经常不命中，没有意义，还增加空间开销。
  • 对于特大型表，建立和使用索引的代价将随之增长。可以考虑使用分区技术或 Nosql。

# 索引的类型

主流的关系型数据库一般都支持以下索引类型：

从逻辑类型上划分（即一般创建表时设置的索引类型）：

  • 唯一索引（UNIQUE）：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。
  • 主键索引（PRIMARY）：一种特殊的唯一索引，一个表只能有一个主键，不允许有空值。一般是在建表的时候同时创建主键索引。
  • 普通索引（INDEX）：最基本的索引，没有任何限制。
  • 组合索引：多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循最左前缀集合。

从物理存储上划分：

  • 聚集索引(Clustered)：表中各行的物理顺序与键值的逻辑（索引）顺序相同，每个表只能有一个。
  • 非聚集索引(Non-clustered)：非聚集索引指定表的逻辑顺序，也可以视为二级索引。数据存储在一个位置，索引存储在另一个位置，索引中包含指向数据存储位置的指针。可以有多个，小于 249 个。

# 索引的数据结构

主流数据库的索引一般使用的数据结构为：B 树、B+ 树。

# B 树

一棵 M 阶的 B-Tree 满足以下条件：

  • 每个结点至多有 M 个孩子；
  • 除根结点和叶结点外，其它每个结点至少有 M/2 个孩子；
  • 根结点至少有两个孩子（除非该树仅包含一个结点）；
  • 所有叶结点在同一层，叶结点不包含任何关键字信息；
  • 有 K 个关键字的非叶结点恰好包含 K+1 个孩子；

对于任意结点，其内部的关键字 Key 是升序排列的。每个节点中都包含了 data。

对于每个结点，主要包含一个关键字数组 Key[]，一个指针数组（指向儿子）Son[]。

在 B-Tree 内，查找的流程是：

  1. 使用顺序查找（数组长度较短时）或折半查找方法查找 Key[] 数组，若找到关键字 K，则返回该结点的地址及 K 在 Key[] 中的位置；
  2. 否则，可确定 K 在某个 Key[i] 和 Key[i+1] 之间，则从 Son[i] 所指的子结点继续查找，直到在某结点中查找成功；
  3. 或直至找到叶结点且叶结点中的查找仍不成功时，查找过程失败。

# B+ 树

B+Tree 是 B-Tree 的变种：

  • 每个节点的指针上限为 2d 而不是 2d+1（d 为节点的出度）。
  • 非叶子节点不存储 data，只存储 key；叶子节点不存储指针。

由于并不是所有节点都具有相同的域，因此 B+Tree 中叶节点和内节点一般大小不同。这点与 B-Tree 不同，虽然 B-Tree 中不同节点存放的 key 和指针可能数量不一致，但是每个节点的域和上限是一致的，所以在实现中 B-Tree 往往对每个节点申请同等大小的空间。

带有顺序访问指针的 B+Tree

一般在数据库系统或文件系统中使用的 B+Tree 结构都在经典 B+Tree 的基础上进行了优化，增加了顺序访问指针。

在 B+Tree 的每个叶子节点增加一个指向相邻叶子节点的指针，就形成了带有顺序访问指针的 B+Tree。

这个优化的目的是为了提高区间访问的性能，例如上图中如果要查询 key 为从 18 到 49 的所有数据记录，当找到 18 后，只需顺着节点和指针顺序遍历就可以一次性访问到所有数据节点，极大提到了区间查询效率。

# B 树 vs. B+ 树

  • B+ 树更适合外部存储(一般指磁盘存储)，由于内节点(非叶子节点)不存储 data，所以一个节点可以存储更多的内节点，每个节点能索引的范围更大更精确。也就是说使用 B+ 树单次磁盘 IO 的信息量相比较 B 树更大，IO 效率更高。
  • Mysql 是关系型数据库，经常会按照区间来访问某个索引列，B+ 树的叶子节点间按顺序建立了链指针，加强了区间访问性，所以 B+ 树对索引列上的区间范围查询很友好。而 B 树每个节点的 key 和 data 在一起，无法进行区间查找。

# Hash

Hash 索引只有精确匹配索引所有列的查询才有效。

对于每一行数据，对所有的索引列计算一个 hashcode。哈希索引将所有的 hashcode 存储在索引中，同时在 Hash 表中保存指向每个数据行的指针。

哈希结构索引的优点：

  • 因为索引数据结构紧凑，所以查询速度非常快。

哈希结构索引的缺点：

  • 哈希索引数据不是按照索引值顺序存储的，所以无法用于排序。
  • 哈希索引不支持部分索引匹配查找。如，在数据列 (A,B) 上建立哈希索引，如果查询只有数据列 A，无法使用该索引。
  • 哈希索引只支持等值比较查询，不支持任何范围查询，如 WHERE price > 100。
  • 哈希索引有可能出现哈希冲突，出现哈希冲突时，必须遍历链表中所有的行指针，逐行比较，直到找到符合条件的行。

# 索引策略

# 索引基本原则

  • 索引不是越多越好，不要为所有列都创建索引。
  • 要尽量避免冗余和重复索引；
  • 要考虑删除未使用的索引；
  • 尽量的扩展索引，不要新建索引；
  • 频繁作为 WHERE 过滤条件的列应该考虑添加索引

# 独立的列

如果查询中的列不是独立的列，则数据库不会使用索引。

“独立的列” 是指索引列不能是表达式的一部分，也不能是函数的参数。

❌ 错误示例：

SELECT actor_id FROM actor WHERE actor_id + 1 = 5;
+SELECT ... WHERE TO_DAYS(current_date) - TO_DAYS(date_col) <= 10;
+

# 前缀索引和索引选择性

有时候需要索引很长的字符列，这会让索引变得大且慢。

解决方法是：可以索引开始的部分字符，这样可以大大节约索引空间，从而提高索引效率。但这样也会降低索引的选择性。

索引的选择性是指：不重复的索引值和数据表记录总数的比值。最大值为 1，此时每个记录都有唯一的索引与其对应。选择性越高，查询效率也越高。

对于 BLOB/TEXT/VARCHAR 这种文本类型的列，必须使用前缀索引，因为数据库往往不允许索引这些列的完整长度。

要选择足够长的前缀以保证较高的选择性，同时又不能太长（节约空间）。

❌ 低效示例：

SELECT COUNT(*) AS cnt, city FROM sakila.city_demo
+GROUP BY city ORDER BY cnt DESC LIMIT 10;
+

✔ 高效示例：

SELECT COUNT(*) AS cnt, LEFT(city, 3) AS pref FROM sakila.city_demo
+GROUP BY city ORDER BY cnt DESC LIMIT 10;
+

# 多列索引

不要为每个列都创建独立索引。

将选择性高的列或基数大的列优先排在多列索引最前列。但有时，也需要考虑 WHERE 子句中的排序、分组和范围条件等因素，这些因素也会对查询性能造成较大影响。

举例来说，有一张 user 表，其中含 name, sex, age 三个列，如果将这三者组合为多列索引，应该用什么样的顺序呢？从选择性高的角度来看：name > age > sex。

# 聚簇索引

聚簇索引不是一种单独的索引类型，而是一种数据存储方式。具体细节依赖于实现方式。如 InnoDB 的聚簇索引实际是在同一个结构中保存了 B 树的索引和数据行。

聚簇表示数据行和相邻的键值紧凑地存储在一起，因为数据紧凑，所以访问快。因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。

若没有定义主键，InnoDB 会隐式定义一个主键来作为聚簇索引。

# 覆盖索引

索引包含所有需要查询的字段的值。

具有以下优点：

  • 因为索引条目通常远小于数据行的大小，所以若只读取索引，能大大减少数据访问量。
  • 一些存储引擎（例如 MyISAM）在内存中只缓存索引，而数据依赖于操作系统来缓存。因此，只访问索引可以不使用系统调用（通常比较费时）。
  • 对于 InnoDB 引擎，若辅助索引能够覆盖查询，则无需访问主索引。

# 使用索引扫描来做排序

Mysql 有两种方式可以生成排序结果：通过排序操作；或者按索引顺序扫描。

索引最好既满足排序，又用于查找行。这样，就可以使用索引来对结果排序。

# 最左前缀匹配原则

MySQL 会一直向右匹配直到遇到范围查询 (>,<,BETWEEN,LIKE) 就停止匹配。

  • 索引可以简单如一个列(a)，也可以复杂如多个列(a, b, c, d)，即联合索引。
  • 如果是联合索引，那么 key 也由多个列组成，同时，索引只能用于查找 key 是否存在（相等），遇到范围查询(>、<、between、like 左匹配)等就不能进一步匹配了，后续退化为线性查找。
  • 因此，列的排列顺序决定了可命中索引的列数。

例子：

  • 如有索引(a, b, c, d)，查询条件 a = 1 and b = 2 and c > 3 and d = 4，则会在每个节点依次命中 a、b、c，无法命中 d。(很简单：索引命中只能是相等的情况，不能是范围匹配)

# = 和 in 可以乱序

不需要考虑=、in 等的顺序，Mysql 会自动优化这些条件的顺序，以匹配尽可能多的索引列。

例子：如有索引(a, b, c, d)，查询条件 c > 3 and b = 2 and a = 1 and d < 4 与 a = 1 and c > 3 and b = 2 and d < 4 等顺序都是可以的，MySQL 会自动优化为 a = 1 and b = 2 and c > 3 and d < 4，依次命中 a、b、c。

# 约束

数据库约束（CONSTRAINT）有哪些：

  • NOT NULL - 用于控制字段的内容一定不能为空（NULL）。
  • UNIQUE - 字段内容不能重复，一个表允许有多个 Unique 约束。
  • PRIMARY KEY - 数据表中对储存数据对象予以唯一和完整标识的数据列或属性的组合，它在一个表中只允许有一个。主键的取值不能为空值（Null）。
  • FOREIGN KEY - 在一个表中存在的另一个表的主键称此表的外键。用于预防破坏表之间连接的动作，也能防止非法数据插入外键列，因为它必须是它指向的那个表中的值之一。
  • CHECK - 用于控制字段的值范围。

# 并发控制

# 乐观锁和悲观锁

  • 数据库的乐观锁和悲观锁是什么？
  • 数据库的乐观锁和悲观锁如何实现？

确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性，乐观锁和悲观锁是并发控制主要采用的技术手段。

  • 悲观锁 - 假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作 +
    • 在查询完数据的时候就把事务锁起来，直到提交事务（COMMIT）
    • 实现方式：使用数据库中的锁机制
  • 乐观锁 - 假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。 +
    • 在修改数据的时候把事务锁起来，通过 version 的方式来进行锁定
    • 实现方式：使用 version 版本或者时间戳

# 行级锁和表级锁

  • 什么是行级锁和表级锁？
  • 什么时候用行级锁？什么时候用表级锁？

从数据库的锁粒度来看，MySQL 中提供了两种封锁粒度：行级锁和表级锁。

  • 表级锁（table lock） - 锁定整张表。用户对表进行写操作前，需要先获得写锁，这会阻塞其他用户对该表的所有读写操作。只有没有写锁时，其他用户才能获得读锁，读锁之间不会相互阻塞。
  • 行级锁（row lock） - 仅对指定的行记录进行加锁，这样其它进程还是可以对同一个表中的其它记录进行操作。

二者需要权衡：

  • 锁定的数据量越少，锁竞争的发生频率就越小，系统的并发程度就越高。
  • 锁粒度越小，系统开销就越大。

在 InnoDB 中，行锁是通过给索引上的索引项加锁来实现的。如果没有索引，InnoDB 将会通过隐藏的聚簇索引来对记录加锁。

# 读写锁

  • 什么是读写锁？
  • 独享锁（Exclusive），简写为 X 锁，又称写锁。使用方式：SELECT ... FOR UPDATE;
  • 共享锁（Shared），简写为 S 锁，又称读锁。使用方式：SELECT ... LOCK IN SHARE MODE;

写锁和读锁的关系，简言之：独享锁存在，其他事务就不能做任何操作。

InnoDB 下的行锁、间隙锁、next-key 锁统统属于独享锁。

# 意向锁

  • 什么是意向锁？
  • 意向锁有什么用？

意向锁的作用是：当存在表级锁和行级锁的情况下，必须先申请意向锁（表级锁，但不是真的加锁），再获取行级锁。使用意向锁（Intention Locks）可以更容易地支持多粒度封锁。

意向锁是 InnoDB 自动加的，不需要用户干预。

# MVCC

什么是 MVCC？

MVCC 有什么用？解决了什么问题？

MVCC 的原理是什么？

多版本并发控制（Multi-Version Concurrency Control, MVCC）是 InnoDB 存储引擎实现隔离级别的一种具体方式，用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行，要求很低，无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。

MVCC 的思想是：

  • 保存数据在某个时间点的快照。写操作（DELETE、INSERT、UPDATE）更新最新的版本快照，而读操作去读旧版本快照，没有互斥关系，这一点和 CopyOnWrite 类似。
  • 脏读和不可重复读最根本的原因是事务读取到其它事务未提交的修改。在事务进行读取操作时，为了解决脏读和不可重复读问题，MVCC 规定只能读取已经提交的快照。当然一个事务可以读取自身未提交的快照，这不算是脏读。

# Next-key 锁

Next-Key 锁是 MySQL 的 InnoDB 存储引擎的一种锁实现。

MVCC 不能解决幻读问题，Next-Key 锁就是为了解决幻读问题。在可重复读（REPEATABLE READ）隔离级别下，使用 MVCC + Next-Key 锁 可以解决幻读问题。

另外，根据针对 SQL 语句检索条件的不同，加锁又有以下三种情形需要我们掌握。

  • Record Lock - 行锁对索引项加锁，若没有索引则使用表锁。
  • Gap Lock - 对索引项之间的间隙加锁。锁定索引之间的间隙，但是不包含索引本身。例如当一个事务执行以下语句，其它事务就不能在 t.c 中插入 15。SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;
  • Next-key lock -它是 Record Lock 和 Gap Lock 的结合，不仅锁定一个记录上的索引，也锁定索引之间的间隙。它锁定一个前开后闭区间。

索引分为主键索引和非主键索引两种，如果一条 SQL 语句操作了主键索引，MySQL 就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL 会先锁定该非主键索引，再锁定相关的主键索引。在 UPDATE、DELETE 操作时，MySQL 不仅锁定 WHERE 条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的 next-key lock。

当两个事务同时执行，一个锁住了主键索引，在等待其他相关索引。另一个锁定了非主键索引，在等待主键索引。这样就会发生死锁。发生死锁后，InnoDB 一般都可以检测到，并使一个事务释放锁回退，另一个获取锁完成事务。

# 事务

事务简单来说：一个 Session 中所进行所有的操作，要么同时成功，要么同时失败。具体来说，事务指的是满足 ACID 特性的一组操作，可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。

img

# ACID

ACID — 数据库事务正确执行的四个基本要素：

  • 原子性（Atomicity）
  • 一致性（Consistency）
  • 隔离性（Isolation）
  • 持久性（Durability）

一个支持事务（Transaction）中的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易。

img

# 并发一致性问题

在并发环境下，事务的隔离性很难保证，因此会出现很多并发一致性问题。

  • 丢失修改

T1 和 T2 两个事务都对一个数据进行修改，T1 先修改，T2 随后修改，T2 的修改覆盖了 T1 的修改。

img

  • 脏读

T1 修改一个数据，T2 随后读取这个数据。如果 T1 撤销了这次修改，那么 T2 读取的数据是脏数据。

img

  • 不可重复读

T2 读取一个数据，T1 对该数据做了修改。如果 T2 再次读取这个数据，此时读取的结果和第一次读取的结果不同。

img

  • 幻读

T1 读取某个范围的数据，T2 在这个范围内插入新的数据，T1 再次读取这个范围的数据，此时读取的结果和和第一次读取的结果不同。

img

并发一致性解决方案：

产生并发不一致性问题主要原因是破坏了事务的隔离性，解决方法是通过并发控制来保证隔离性。

并发控制可以通过封锁来实现，但是封锁操作需要用户自己控制，相当复杂。数据库管理系统提供了事务的隔离级别，让用户以一种更轻松的方式处理并发一致性问题。

# 事务隔离

数据库隔离级别：

  • 未提交读（READ UNCOMMITTED） - 事务中的修改，即使没有提交，对其它事务也是可见的。
  • 提交读（READ COMMITTED） - 一个事务只能读取已经提交的事务所做的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的。
  • 重复读（REPEATABLE READ） - 保证在同一个事务中多次读取同样数据的结果是一样的。
  • 串行化（SERIALIXABLE） - 强制事务串行执行。

数据库隔离级别解决的问题：

隔离级别 脏读 不可重复读 幻读
未提交读 ❌ ❌ ❌
提交读 ✔️ ❌ ❌
可重复读 ✔️ ✔️ ❌
可串行化 ✔️ ✔️ ✔️

# 分布式事务

在单一数据节点中，事务仅限于对单一数据库资源的访问控制，称之为 本地事务。几乎所有的成熟的关系型数据库都提供了对本地事务的原生支持。

分布式事务 是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

# 两阶段提交

两阶段提交（XA）对业务侵入很小。 它最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于 XA 协议的分布式事务。 XA 协议能够严格保障事务 ACID 特性。

严格保障事务 ACID 特性是一把双刃剑。 事务执行在过程中需要将所需资源全部锁定，它更加适用于执行时间确定的短事务。 对于长事务来说，整个事务进行期间对数据的独占，将导致对热点数据依赖的业务系统并发性能衰退明显。 因此，在高并发的性能至上场景中，基于 XA 协议的分布式事务并不是最佳选择。

# 柔性事务

如果将实现了ACID 的事务要素的事务称为刚性事务的话，那么基于BASE事务要素的事务则称为柔性事务。 BASE是基本可用、柔性状态和最终一致性这三个要素的缩写。

  • 基本可用（Basically Available）保证分布式事务参与方不一定同时在线。
  • 柔性状态（Soft state）则允许系统状态更新有一定的延时，这个延时对客户来说不一定能够察觉。
  • 而最终一致性（Eventually consistent）通常是通过消息传递的方式保证系统的最终一致性。

在ACID事务中对隔离性的要求很高，在事务执行过程中，必须将所有的资源锁定。 柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性要求，来换取系统吞吐量的提升。

基于ACID的强一致性事务和基于BASE的最终一致性事务都不是银弹，只有在最适合的场景中才能发挥它们的最大长处。 可通过下表详细对比它们之间的区别，以帮助开发者进行技术选型。

# 事务方案对比

本地事务 两（三）阶段事务 柔性事务
业务改造 无 无 实现相关接口
一致性 不支持 支持 最终一致
隔离性 不支持 支持 业务方保证
并发性能 无影响 严重衰退 略微衰退
适合场景 业务方处理不一致 短事务 & 低并发 长事务 & 高并发

# 分库分表

# 什么是分库分表

什么是分库分表？什么是垂直拆分？什么是水平拆分？什么是 Sharding？

分库分表是为了解决什么问题？

分库分表有什么优点？

分库分表有什么策略？

分库分表的基本思想就是：把原本完整的数据切分成多个部分，放到不同的数据库或表上。

分库分表一定是为了支撑 高并发、数据量大两个问题的。

# 垂直切分

垂直切分，是 把一个有很多字段的表给拆分成多个表，或者是多个库上去。一般来说，会 将较少的、访问频率较高的字段放到一个表里去，然后 将较多的、访问频率较低的字段放到另外一个表里去。因为数据库是有缓存的，访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。

image-20200114211639899

一般来说，满足下面的条件就可以考虑扩容了：

  • Mysql 单库超过 5000 万条记录，Oracle 单库超过 1 亿条记录，DB 压力就很大。
  • 单库超过每秒 2000 个并发时，而一个健康的单库最好保持在每秒 1000 个并发左右，不要太大。

在数据库的层面使用垂直切分将按数据库中表的密集程度部署到不同的库中，例如将原来的电商数据库垂直切分成商品数据库、用户数据库等。

# 水平拆分

水平拆分 又称为 Sharding，它是将同一个表中的记录拆分到多个结构相同的表中。当 单表数据量太大 时，会极大影响 SQL 执行的性能 。分表是将原来一张表的数据分布到数据库集群的不同节点上，从而缓解单点的压力。

image-20200114211203589

一般来说，单表有 200 万条数据 的时候，性能就会相对差一些了，需要考虑分表了。但是，这也要视具体情况而定，可能是 100 万条，也可能是 500 万条，SQL 越复杂，就最好让单表行数越少。

# 分库分表的优点

# 分库分表前 分库分表后
并发支撑情况 单机部署，扛不住高并发 从单机到多机，能承受的并发增加了多倍
磁盘使用情况 单机磁盘容量几乎撑满 拆分为多个库，数据库服务器磁盘使用率大大降低
SQL 执行性能 单表数据量太大，SQL 越跑越慢 单表数据量减少，SQL 执行效率明显提升

# 分库分表策略

  • 哈希取模：hash(key) % N 或 id % N
    • 优点：可以平均分配每个库的数据量和请求压力（负载均衡）。
    • 缺点：扩容麻烦，需要数据迁移。
  • 范围：可以按照 ID 或时间划分范围。 +
    • 优点：扩容简单。
    • 缺点：这种策略容易产生热点问题。
  • 映射表：使用单独的一个数据库来存储映射关系。 +
    • 缺点：存储映射关系的数据库也可能成为性能瓶颈，且一旦宕机，分库分表的数据库就无法工作。所以不建议使用这种策略。
    • 优点：扩容简单，可以解决分布式 ID 问题。

# 分库分表中间件

❓ 常见问题：

  • 你用过哪些分库分表中间件，简单介绍一下？

  • 不同的分库分表中间件各自有什么特性，有什么优缺点？

  • 分库分表中间件技术如何选型？

# 常见的分库分表中间件

  • Cobar (opens new window) - 阿里 b2b 团队开发和开源的，属于 proxy 层方案，就是介于应用服务器和数据库服务器之间。应用程序通过 JDBC 驱动访问 cobar 集群，cobar 根据 SQL 和分库规则对 SQL 做分解，然后分发到 MySQL 集群不同的数据库实例上执行。早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。
  • TDDL (opens new window) - 淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。目前使用的也不多，因为还依赖淘宝的 diamond 配置管理系统。
  • Atlas (opens new window) - 360 开源的，属于 proxy 层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以，现在用的公司基本也很少了。
  • sharding-jdbc (opens new window) - 当当开源的，属于 client 层方案。确实之前用的还比较多一些，因为 SQL 语法支持也比较多，没有太多限制，而且目前推出到了 2.0 版本，支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从 2017 年一直到现在，是有不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，个人认为算是一个现在也可以选择的方案。
  • Mycat (opens new window) - 基于 cobar 改造的，属于 proxy 层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于 sharding jdbc 来说，年轻一些，经历的锤炼少一些。

# 分库分表中间件技术选型

建议使用的是 sharding-jdbc 和 mycat。

  • sharding-jdbc (opens new window) 这种 client 层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合 sharding-jdbc 的依赖。其本质上通过配置多数据源，然后根据设定的分库分表策略，计算路由，将请求发送到计算得到的节点上。

  • Mycat (opens new window) 这种 proxy 层方案的缺点在于需要部署，自己运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。

通常来说，这两个方案其实都可以选用，但是我个人建议中小型公司选用 sharding-jdbc，client 层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多；但是中大型公司最好还是选用 mycat 这类 proxy 层方案，因为可能大公司系统和项目非常多，团队很大，人员充足，那么最好是专门弄个人来研究和维护 mycat，然后大量项目直接透明使用即可。

# 分库分表的问题

  • 分库分表的常见问题有哪些？

  • 你是如何解决分库分表的问题的？

下文一一讲解常见分库分表的问题及解决方案。

# 分布式事务

方案一：使用数据库事务

  • 优点：交由数据库管理，简单有效
  • 缺点：性能代价高，特别是 shard 越来越多时

方案二：由应用程序和数据库共同控制

  • 原理：将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务，并通过应用程序来总控各个小事务。
  • 优点：性能上有优势
  • 缺点：需要应用程序在事务控制上做灵活设计。如果使用了 spring 的事务管理，改动起来会面临一定的困难。

# 跨节点 Join

只要是进行切分，跨节点 Join 的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的 id，根据这些 id 发起第二次请求得到关联数据。

# 跨节点的 count,order by,group by 以及聚合函数

这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。

解决方案：与解决跨节点 join 问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和 join 不同的是每个节点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。

业务角度上的解决方案：

  • 如果是在前台应用提供分页，则限定用户只能看前面 n 页，这个限制在业务上也是合理的，一般看后面的分页意义不大（如果一定要看，可以要求用户缩小范围重新查询）。
  • 如果是后台批处理任务要求分批获取数据，则可以加大 page size，比如每次获取 5000 条记录，有效减少分页数（当然离线访问一般走备库，避免冲击主库）。
  • 分库设计时，一般还有配套大数据平台汇总所有分库的记录，有些分页查询可以考虑走大数据平台。

# 分布式 ID

一旦数据库被切分到多个物理节点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的 ID 无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得 ID，以便进行 SQL 路由。

一些常见的主键生成策略：

  • 使用全局唯一 ID：GUID。
  • 为每个分片指定一个 ID 范围。
  • 分布式 ID 生成器 (如 Twitter 的 Snowflake 算法)。

# 数据迁移，容量规划，扩容等问题

来自淘宝综合业务平台团队，它利用对 2 的倍数取余具有向前兼容的特性（如对 4 取余得 1 的数对 2 取余也是 1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了 Sharding 扩容的难度。

# 集群

这个专题需要根据熟悉哪个数据库而定，但是主流、成熟的数据库都会实现一些基本功能，只是实现方式、策略上有所差异。由于本人较为熟悉 Mysql，所以下面主要介绍 Mysql 系统架构问题。

# 复制机制

Mysql 支持两种复制：基于行的复制和基于语句的复制。

这两种方式都是在主库上记录二进制日志（binlog），然后在从库上以异步方式更新主库上的日志记录。这意味着：复制过程存在时延，这段时间内，主从数据可能不一致（即最终一致性）。

主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。

  • binlog 线程 ：负责将主服务器上的数据更改写入二进制文件（binlog）中。
  • I/O 线程 ：负责从主服务器上读取二进制日志文件，并写入从服务器的日志中。
  • SQL 线程 ：负责读取日志并执行 SQL 语句以更新数据。

img

# 读写分离

主服务器用来处理写操作以及实时性要求比较高的读操作，而从服务器用来处理读操作。

读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。

MySQL 读写分离能提高性能的原因在于：

  • 主从服务器负责各自的读和写，极大程度缓解了锁的争用；
  • 从服务器可以配置 MyISAM 引擎，提升查询性能以及节约系统开销；
  • 增加冗余，提高可用性。

img

# 数据库优化

数据库优化的路线一般为：SQL 优化、结构优化、配置优化、硬件优化。前两个方向一般是普通开发的考量点，而后两个方向一般是 DBA 的考量点。

# SQL 优化

SQL 优化是数据库优化的最常见、最初级手段。

在执行 SQL 语句，语句中字段的顺序、查询策略等都可能会影响到 SQL 的执行性能。

# 执行计划

如何检验修改后的 SQL 确实有优化效果？这就需要用到执行计划（EXPLAIN）。

使用执行计划 EXPLAIN 用来分析 SELECT 查询效率，开发人员可以通过分析 EXPLAIN 结果来优化查询语句。

比较重要的字段有：

  • select_type - 查询类型，有简单查询、联合查询、子查询等
  • key - 使用的索引
  • rows - 扫描的行数

更多内容请参考：MySQL 性能优化神器 Explain 使用分析 (opens new window)

# 访问数据优化

减少请求的数据量：

  • 只返回必要的列 - 不要查询不需要的列，尽量避免使用 SELECT * 语句。
  • 只返回必要的行 - 使用 WHERE 语句进行查询过滤，有时候也需要使用 LIMIT 语句来限制返回的数据。
  • 缓存重复查询的数据 - 使用缓存可以避免在数据库中进行查询，特别要查询的数据经常被重复查询，缓存可以带来的查询性能提升将会是非常明显的。

减少服务器端扫描的行数：

  • 最有效的方式是使用索引来覆盖查询（即 WHERE 后的过滤查询字段最好是索引字段）。

# 重构查询方式

# 切分查询

一个大查询如果一次性执行的话，可能一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。

DELEFT FROM messages WHERE create < DATE_SUB(NOW(), INTERVAL 3 MONTH);
+
rows_affected = 0
+do {
+    rows_affected = do_query(
+    "DELETE FROM messages WHERE create  < DATE_SUB(NOW(), INTERVAL 3 MONTH) LIMIT 10000")
+} while rows_affected > 0
+
# 分解关联查询

将一个大连接查询（JOIN）分解成对每一个表进行一次单表查询，然后将结果在应用程序中进行关联，这样做的好处有：

  • 缓存更高效。对于连接查询，如果其中一个表发生变化，那么整个查询缓存就无法使用。而分解后的多个查询，即使其中一个表发生变化，对其它表的查询缓存依然可以使用。
  • 分解成多个单表查询，这些单表查询的缓存结果更可能被其它查询使用到，从而减少冗余记录的查询。
  • 减少锁竞争；
  • 在应用层进行连接，可以更容易对数据库进行拆分，从而更容易做到高性能和可扩展。
  • 查询本身效率也可能会有所提升。例如下面的例子中，使用 IN() 代替连接查询，可以让 MySQL 按照 ID 顺序进行查询，这可能比随机的连接要更高效。
SELECT * FROM tag
+JOIN tag_post ON tag_post.tag_id=tag.id
+JOIN post ON tag_post.post_id=post.id
+WHERE tag.tag='mysql';
+SELECT * FROM tag WHERE tag='mysql';
+SELECT * FROM tag_post WHERE tag_id=1234;
+SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);
+

# SQL 语句细节

# 选择最有效率的表名顺序

数据库按照从右到左的顺序处理 FROM 子句中的表名，FROM 子句中写在最后的表将被最先处理。

在 FROM 子句中包含多个表的情况下：

  • 如果多个表是完全无关系的话，将记录和列名最少的表，写在最后，然后依次类推。也就是说：选择记录条数最少的表放在最后。

如果有 3 个以上的表连接查询：

  • 如果多个表是有关系的话，将引用最多的表，放在最后，然后依次类推。也就是说：被其他表所引用的表放在最后。

例如：查询员工的编号，姓名，工资，工资等级，部门名

emp 表被引用得最多，记录数也是最多，因此放在 form 字句的最后面

select emp.empno,emp.ename,emp.sal,salgrade.grade,dept.dname
+from salgrade,dept,emp
+where (emp.deptno = dept.deptno) and (emp.sal between salgrade.losal and salgrade.hisal)
+
# WHERE 子句中的连接顺序

数据库按照从右到左的顺序解析 WHERE 子句。

因此，表之间的连接必须写在其他 WHERE 条件的左边，那些可以过滤掉最大数量记录的条件必须写在 WHERE 子句的之右。

emp.sal 可以过滤多条记录，写在 WHERE 字句的最右边

select emp.empno,emp.ename,emp.sal,dept.dname
+from dept,emp
+where (emp.deptno = dept.deptno) and (emp.sal > 1500)
+
# SELECT 子句中避免使用 * 号

我们当时学习的时候，“*” 号是可以获取表中全部的字段数据的。

  • 但是它要通过查询数据字典完成的，这意味着将耗费更多的时间
  • 使用*号写出来的 SQL 语句也不够直观。
# 用 TRUNCATE 替代 DELETE

如果需要清空所有表记录，使用 TRUNCATE 比 DELETE 执行效率高：

DELETE 是一条一条记录的删除，而 Truncate 是将整个表删除，仅保留表结构

# 使用内部函数提高 SQL 效率

例如使用 mysql 的 concat() 函数会比使用 || 拼接速度快，因为 concat() 函数已经被 mysql 优化过了。

# 使用表或列的别名

如果表或列的名称太长了，使用一些简短的别名也能稍微提高一些 SQL 的性能。毕竟要扫描的字符长度就变少了。

# SQL 关键字大写

我们在编写 SQL 的时候，官方推荐的是使用大写来写关键字，因为 Oracle 服务器总是先将小写字母转成大写后，才执行

# 用 >= 替代 >

❌ 低效方式：

-- 首先定位到DEPTNO=3的记录并且扫描到第一个DEPT大于3的记录
+SELECT * FROM EMP WHERE DEPTNO > 3
+

✔ 高效方式：

-- 直接跳到第一个DEPT等于4的记录
+SELECT * FROM EMP WHERE DEPTNO >= 4
+
# 用 IN 替代 OR

❌ 低效方式：

select * from emp where sal = 1500 or sal = 3000 or sal = 800;
+

✔ 高效方式：

select * from emp where sal in (1500,3000,800);
+
# 总是使用索引的第一个列

如果索引是建立在多个列上，只有在它的第一个列被 WHERE 子句引用时，优化器才会选择使用该索引。 当只引用索引的第二个列时，不引用索引的第一个列时，优化器使用了全表扫描而忽略了索引

create index emp_sal_job_idex
+on emp(sal,job);
+----------------------------------
+select *
+from emp
+where job != 'SALES';
+
# SQL 关键字尽量大写

SQL 关键字尽量大写，如：Oracle 默认会将 SQL 语句中的关键字转为大写后在执行。

# 结构优化

数据库结构优化可以从以下方向着手：

  • 数据类型优化
  • 范式和反范式优化
  • 索引优化 - 细节请看索引和约束章节
  • 分库分表 - 细节请看分库分表章节

# 数据类型优化原则

  • 更小的通常更好
  • 简单就好，如整型比字符型操作代价低
  • 尽量避免 NULL

# 范式和反范式

范式和反范式各有利弊，需要根据实际情况权衡。

范式化的目标是尽力减少冗余列，节省空间。

  • 范式化的优点是：

    • 减少冗余列，要写的数据就少，写操作的性能提高；
    • 检索列数据时，DISTINCT 或 GROUP BY 操作减少。

  • 范式化的缺点是：增加关联查询。

反范式化的目标是适当增加冗余列，以避免关联查询。

反范式化的缺点是：

  • 冗余列增多，空间变大，写操作性能下降；
  • 检索列数据时，DISTINCT 或 GROUP BY 操作变多；

# 配置优化

配置优化主要是针对 Mysql 服务器，例如：max_connections、max_heap_table_size、open_files_limit、max_allowed_packet 等等。

在不同环境，不同场景下，应该酌情使用合理的配置。这种优化比较考验 Mysql 运维经验，一般是 DBA 的考量，普通开发接触的较少。

Mysql 配置说明请参考：Mysql 服务器配置说明

# 硬件优化

数据库扩容、使用高配设备等等。核心就是一个字：钱。

# 数据库理论

# 函数依赖

记 A->B 表示 A 函数决定 B，也可以说 B 函数依赖于 A。

如果 {A1，A2，... ，An} 是关系的一个或多个属性的集合，该集合函数决定了关系的其它所有属性并且是最小的，那么该集合就称为键码。

对于 A->B，如果能找到 A 的真子集 A'，使得 A'-> B，那么 A->B 就是部分函数依赖，否则就是完全函数依赖；

对于 A->B，B->C，则 A->C 是一个传递依赖。

# 异常

以下的学生课程关系的函数依赖为 Sno, Cname -> Sname, Sdept, Mname, Grade，键码为 {Sno, Cname}。也就是说，确定学生和课程之后，就能确定其它信息。

Sno Sname Sdept Mname Cname Grade
1 学生-1 学院-1 院长-1 课程-1 90
2 学生-2 学院-2 院长-2 课程-2 80
2 学生-2 学院-2 院长-2 课程-1 100
3 学生-3 学院-2 院长-2 课程-2 95

不符合范式的关系，会产生很多异常，主要有以下四种异常：

  • 冗余数据：例如 学生-2 出现了两次。
  • 修改异常：修改了一个记录中的信息，但是另一个记录中相同的信息却没有被修改。
  • 删除异常：删除一个信息，那么也会丢失其它信息。例如如果删除了 课程-1，需要删除第一行和第三行，那么 学生-1 的信息就会丢失。
  • 插入异常，例如想要插入一个学生的信息，如果这个学生还没选课，那么就无法插入。

# 范式

范式理论是为了解决以上提到四种异常。

高级别范式的依赖于低级别的范式，1NF 是最低级别的范式。

# 第一范式 (1NF)

属性不可分。

# 第二范式 (2NF)

  • 每个非主属性完全函数依赖于键码。

  • 可以通过分解来满足。

分解前

Sno Sname Sdept Mname Cname Grade
1 学生-1 学院-1 院长-1 课程-1 90
2 学生-2 学院-2 院长-2 课程-2 80
2 学生-2 学院-2 院长-2 课程-1 100
3 学生-3 学院-2 院长-2 课程-2 95

以上学生课程关系中，{Sno, Cname} 为键码，有如下函数依赖：

  • Sno -> Sname, Sdept
  • Sdept -> Mname
  • Sno, Cname-> Grade

Grade 完全函数依赖于键码，它没有任何冗余数据，每个学生的每门课都有特定的成绩。

Sname, Sdept 和 Mname 都部分依赖于键码，当一个学生选修了多门课时，这些数据就会出现多次，造成大量冗余数据。

分解后

关系-1

Sno Sname Sdept Mname
1 学生-1 学院-1 院长-1
2 学生-2 学院-2 院长-2
3 学生-3 学院-2 院长-2

有以下函数依赖：

  • Sno -> Sname, Sdept, Mname
  • Sdept -> Mname

关系-2

Sno Cname Grade
1 课程-1 90
2 课程-2 80
2 课程-1 100
3 课程-2 95

有以下函数依赖：

  • Sno, Cname -> Grade

# 第三范式 (3NF)

  • 非主属性不传递依赖于键码。

上面的 关系-1 中存在以下传递依赖：Sno -> Sdept -> Mname，可以进行以下分解：

关系-11

Sno Sname Sdept
1 学生-1 学院-1
2 学生-2 学院-2
3 学生-3 学院-2

关系-12

Sdept Mname
学院-1 院长-1
学院-2 院长-2

# 存储引擎

Mysql 有多种存储引擎，不同的存储引擎保存数据和索引的方式是不同的，但表的定义则是在 Mysql 服务层统一处理的。

简单列举几个存储引擎：

  • InnoDB - Mysql 的默认事务型存储引擎，并提供了行级锁和外键的约束。性能不错且支持自动故障恢复。
  • MyISAM - Mysql 5.1 版本前的默认存储引擎。特性丰富但不支持事务，也不支持行级锁和外键，也没有故障恢复功能。
  • CSV - 可以将 CSV 文件作为 Mysql 的表来处理，但这种表不支持索引。
  • MEMORY 。所有的数据都在内存中，数据的处理速度快，但是安全性不高。

# InnoDB vs. MyISAM

InnoDB 和 MyISAM 是目前使用的最多的两种 Mysql 存储引擎。

  • 数据结构比较： +
    • InnoDB 和 MyISAM 的索引数据结构都是 B+ 树。
    • MyIASM 的 B+ 树中存储的内容实际上是实际数据的地址值。也就是说它的索引和实际数据是分开的，只不过使用索引指向了实际数据。这种索引的模式被称为非聚集索引。
    • InnoDB 的 B+ 树中存储的内容是实际的数据，这种索引有被称为聚集索引。
  • 事务支持比较： +
    • InnoDB 支持事务，并提供了行级锁和外键的约束。
    • MyIASM 不支持事务，也不支持行级锁和外键。
  • 故障恢复比较： +
    • InnoDB 支持故障恢复。
    • MyISAM 不支持故障恢复。

# 数据库比较

# 常见数据库比较

  • Oracle - 久负盛名的商业数据库。功能强大、稳定。最大的缺点就是费钱。
  • Mysql - 曾经是互联网公司的最爱，但自动 Mysql 被 Oracle 公司收购后，好日子可能一去不复返。很多公司或开源项目已经逐渐寻找其他的开源产品来替代 Mysql。
  • MariaDB - 开源关系型数据库。 MySQL 的真正开源的发行版本，由 Mysql 部分核心人员创建。可作为 Mysql 的替代产品。
  • PostgreSQL - 开源关系型数据库。和 MySQL 的工作方式非常相似，社区支持做得很好。可作为 Mysql 的替代产品。
  • SQLite - 开源的轻量级数据库，移动端常常使用。
  • H2 - 内存数据库，一般用作开发、测试环境数据库。
  • SQL Server - 微软 Windows 生态系统的数据库。我想，Java 程序员应该没人用吧。

# Oracle vs. Mysql

目前为止，Java 领域用的最多的关系型数据库，应该还是 Oracle 和 Mysql，所以这里做一下比较。

# 数据库对象差异

在 Mysql 中，一个用户可以创建多个库。

而在 Oracle 中，Oracle 服务器是由两部分组成

  • 数据库实例【理解为对象，看不见的】
  • 数据库【理解为类，看得见的】

一个数据库实例可拥有多个用户，一个用户默认拥有一个表空间。

表空间是存储我们数据库表的地方，表空间内可以有多个文件。

# SQL 差异

（1）主键递增

Mysql 可以设置 AUTO_INCREMENT 约束来指定主键为自增序列。

Oracle 需要通过 CREATE SEQUENCE 创建序列。

（2）分页查询

Mysql 分页基于 SELECT ... FROM ... LIMIT ... 完成，较简单。

select * from help_category order by parent_category_id limit 10,5;
+

Oracle 分页基于 SELECT ... FROM (SELECT ROWNUM ...) WHERE ... 完成，较复杂。

select * from
+(select rownum rr,a.* from (select * from emp order by sal) a )
+where rr>5 and rr<=10;
+

# 事务差异

  • auto commit +
    • Mysql 事务是 autocommit 模式，即自动提交事务；
    • Oracle 事务需要手动 COMMIT。
  • 事务隔离级别 +
    • Mysql 默认的事务隔离级别是可重复读（REPEATABLE READ）
    • Oracle 支持读已提交（READ COMMITTED）和串行化（SERIALIZABLE） 两种事务隔离级别，默认事务隔离级别是读已提交（READ COMMITTED）

# 数据类型比较

不同数据库中，对数据类型的支持是不一样的。

即使存在同一种数据类型，也可能存在名称不同、或大小不同等问题。

因此，对于数据类型的支持详情必须参考各数据库的官方文档。

下面列举一些常见数据类型对比：

数据类型 Oracle MySQL PostgreSQL
boolean Byte N/A Boolean
integer Number Int Integer Int Integer
float Number Float Numeric
currency N/A N/A Money
string (fixed) Char Char Char
string (variable) Varchar Varchar2 Varchar Varchar
binary object Long Raw Blob Text Binary Varbinary

数据类型对比表摘自 SQL 通用数据类型 (opens new window)、SQL 用于各种数据库的数据类型 (opens new window)

# SQL FAQ

# SELECT COUNT(*)、SELECT COUNT(1) 和 SELECT COUNT(具体字段) 性能有差别吗？

在 MySQL InnoDB 存储引擎中，COUNT(*) 和 COUNT(1) 都是对所有结果进行 COUNT。因此COUNT(*)和COUNT(1)本质上并没有区别，执行的复杂度都是 O(N)，也就是采用全表扫描，进行循环 + 计数的方式进行统计。

如果是 MySQL MyISAM 存储引擎，统计数据表的行数只需要O(1)的复杂度，这是因为每张 MyISAM 的数据表都有一个 meta 信息存储了row_count值，而一致性则由表级锁来保证。因为 InnoDB 支持事务，采用行级锁和 MVCC 机制，所以无法像 MyISAM 一样，只维护一个row_count变量，因此需要采用扫描全表，进行循环 + 计数的方式来完成统计。

需要注意的是，在实际执行中，COUNT(*)和COUNT(1)的执行时间可能略有差别，不过你还是可以把它俩的执行效率看成是相等的。

另外在 InnoDB 引擎中，如果采用COUNT(*)和COUNT(1)来统计数据行数，要尽量采用二级索引。因为主键采用的索引是聚簇索引，聚簇索引包含的信息多，明显会大于二级索引（非聚簇索引）。对于COUNT(*)和COUNT(1)来说，它们不需要查找具体的行，只是统计行数，系统会自动采用占用空间更小的二级索引来进行统计。

然而如果想要查找具体的行，那么采用主键索引的效率更高。如果有多个二级索引，会使用 key_len 小的二级索引进行扫描。当没有二级索引的时候，才会采用主键索引来进行统计。

这里我总结一下：

  1. 一般情况下，三者执行的效率为 COUNT(*)= COUNT(1)> COUNT(字段)。我们尽量使用COUNT(*)，当然如果你要统计的是某个字段的非空数据行数，则另当别论，毕竟比较执行效率的前提是结果一样才可以。
  2. 如果要统计COUNT(*)，尽量在数据表上建立二级索引，系统会自动采用key_len小的二级索引进行扫描，这样当我们使用SELECT COUNT(*)的时候效率就会提升，有时候可以提升几倍甚至更高。

——摘自极客时间 - SQL 必知必会 (opens new window)

# ORDER BY 是对分的组排序还是对分组中的记录排序呢？

ORDER BY 就是对记录进行排序。如果你在 ORDER BY 前面用到了 GROUP BY，实际上这是一种分组的聚合方式，已经把一组的数据聚合成为了一条记录，再进行排序的时候，相当于对分的组进行了排序。

# SELECT 语句内部的执行步骤

一条完整的 SELECT 语句内部的执行顺序是这样的：

  1. FROM 子句组装数据（包括通过 ON 进行连接）；
  2. WHERE 子句进行条件筛选；
  3. GROUP BY 分组 ；
  4. 使用聚集函数进行计算；
  5. HAVING 筛选分组；
  6. 计算所有的表达式；
  7. SELECT 的字段；
  8. ORDER BY 排序；
  9. LIMIT 筛选。

——摘自极客时间 - SQL 必知必会 (opens new window)

# 解哪种情况下应该使用 EXISTS，哪种情况应该用 IN

索引是个前提，其实选择与否还是要看表的大小。你可以将选择的标准理解为小表驱动大表。在这种方式下效率是最高的。

比如下面这样：

 SELECT * FROM A WHERE cc IN (SELECT cc FROM B)
+ SELECT * FROM A WHERE EXISTS (SELECT cc FROM B WHERE B.cc=A.cc)
+

当 A 小于 B 时，用 EXISTS。因为 EXISTS 的实现，相当于外表循环，实现的逻辑类似于：

 for i in A
+     for j in B
+         if j.cc == i.cc then ...
+

当 B 小于 A 时用 IN，因为实现的逻辑类似于：

 for i in B
+     for j in A
+         if j.cc == i.cc then ...
+

哪个表小就用哪个表来驱动，A 表小就用 EXISTS，B 表小就用 IN。

——摘自极客时间 - SQL 必知必会 (opens new window)

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#面试
上次更新: 2023/06/29, 22:27:04
版本管理中间件 Flyway
SQL 语法基础特性

+ ← + SQL 语法基础特性→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/a3347e/index.html b/pages/a3347e/index.html new file mode 100644 index 00000000..251d25c2 --- /dev/null +++ b/pages/a3347e/index.html @@ -0,0 +1,216 @@ + + + + + + HBase Java API 高级特性之过滤器 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2023-03-16
目录

HBase Java API 高级特性之过滤器

# HBase Java API 高级特性之过滤器

HBase 中两种主要的数据读取方法是 get() 和 scan()，它们都支持直接访问数据和通过指定起止 row key 访问数据。此外，可以指定列族、列、时间戳和版本号来进行条件查询。它们的缺点是不支持细粒度的筛选功能。为了弥补这种不足，Get 和 Scan 支持通过过滤器（Filter）对 row key、列或列值进行过滤。

HBase 提供了一些内置过滤器，也允许用户通过继承 Filter 类来自定义过滤器。所有的过滤器都在服务端生效，称为 谓词下推。这样可以保证被过滤掉的数据不会被传到客户端。

图片来自 HBase 权威指南

HBase 过滤器层次结构的最底层是 Filter 接口和 FilterBase 抽象类。大部分过滤器都直接继承自 FilterBase。

# 比较过滤器

所有比较过滤器均继承自 CompareFilter。CompareFilter 比 FilterBase 多了一个 compare() 方法，它需要传入参数定义比较操作的过程：比较运算符和比较器。

创建一个比较过滤器需要两个参数，分别是比较运算符和比较器实例。

 public CompareFilter(final CompareOp compareOp,final ByteArrayComparable comparator) {
+    this.compareOp = compareOp;
+    this.comparator = comparator;
+  }
+

# 比较运算符

  • LESS (<)
  • LESS_OR_EQUAL (<=)
  • EQUAL (=)
  • NOT_EQUAL (!=)
  • GREATER_OR_EQUAL (>=)
  • GREATER (>)
  • NO_OP (排除所有符合条件的值)

比较运算符均定义在枚举类 CompareOperator 中

@InterfaceAudience.Public
+public enum CompareOperator {
+  LESS,
+  LESS_OR_EQUAL,
+  EQUAL,
+  NOT_EQUAL,
+  GREATER_OR_EQUAL,
+  GREATER,
+  NO_OP,
+}
+

注意：在 1.x 版本的 HBase 中，比较运算符定义在 CompareFilter.CompareOp 枚举类中，但在 2.0 之后这个类就被标识为 @deprecated ，并会在 3.0 移除。所以 2.0 之后版本的 HBase 需要使用 CompareOperator 这个枚举类。

# 比较器

所有比较器均继承自 ByteArrayComparable 抽象类，常用的有以下几种：

  • BinaryComparator : 使用 Bytes.compareTo(byte []，byte []) 按字典序比较指定的字节数组。
  • BinaryPrefixComparator : 按字典序与指定的字节数组进行比较，但只比较到这个字节数组的长度。
  • RegexStringComparator : 使用给定的正则表达式与指定的字节数组进行比较。仅支持 EQUAL 和 NOT_EQUAL 操作。
  • SubStringComparator : 测试给定的子字符串是否出现在指定的字节数组中，比较不区分大小写。仅支持 EQUAL 和 NOT_EQUAL 操作。
  • NullComparator ：判断给定的值是否为空。
  • BitComparator ：按位进行比较。

BinaryPrefixComparator 和 BinaryComparator 的区别不是很好理解，这里举例说明一下：

在进行 EQUAL 的比较时，如果比较器传入的是 abcd 的字节数组，但是待比较数据是 abcdefgh：

  • 如果使用的是 BinaryPrefixComparator 比较器，则比较以 abcd 字节数组的长度为准，即 efgh 不会参与比较，这时候认为 abcd 与 abcdefgh 是满足 EQUAL 条件的；
  • 如果使用的是 BinaryComparator 比较器，则认为其是不相等的。

# 比较过滤器种类

比较过滤器共有五个（Hbase 1.x 版本和 2.x 版本相同）：

  • RowFilter ：基于行键来过滤数据；
  • FamilyFilterr ：基于列族来过滤数据；
  • QualifierFilterr ：基于列限定符（列名）来过滤数据；
  • ValueFilterr ：基于单元格 (cell) 的值来过滤数据；
  • DependentColumnFilter ：指定一个参考列来过滤其他列的过滤器，过滤的原则是基于参考列的时间戳来进行筛选 。

前四种过滤器的使用方法相同，均只要传递比较运算符和运算器实例即可构建，然后通过 setFilter 方法传递给 scan：

 Filter filter  = new RowFilter(CompareOperator.LESS_OR_EQUAL,
+                                new BinaryComparator(Bytes.toBytes("xxx")));
+  scan.setFilter(filter);
+

DependentColumnFilter 的使用稍微复杂一点，这里单独做下说明。

# DependentColumnFilter

可以把 DependentColumnFilter 理解为一个 valueFilter 和一个时间戳过滤器的组合。DependentColumnFilter 有三个带参构造器，这里选择一个参数最全的进行说明：

DependentColumnFilter(final byte [] family, final byte[] qualifier,
+                               final boolean dropDependentColumn, final CompareOperator op,
+                               final ByteArrayComparable valueComparator)
+
  • family ：列族
  • qualifier ：列限定符（列名）
  • dropDependentColumn ：决定参考列是否被包含在返回结果内，为 true 时表示参考列被返回，为 false 时表示被丢弃
  • op ：比较运算符
  • valueComparator ：比较器

这里举例进行说明：

DependentColumnFilter dependentColumnFilter = new DependentColumnFilter(
+    Bytes.toBytes("student"),
+    Bytes.toBytes("name"),
+    false,
+    CompareOperator.EQUAL,
+    new BinaryPrefixComparator(Bytes.toBytes("xiaolan")));
+
  • 首先会去查找 student:name 中值以 xiaolan 开头的所有数据获得 参考数据集，这一步等同于 valueFilter 过滤器；
  • 其次再用参考数据集中所有数据的时间戳去检索其他列，获得时间戳相同的其他列的数据作为 结果数据集，这一步等同于时间戳过滤器；
  • 最后如果 dropDependentColumn 为 true，则返回 参考数据集+结果数据集，若为 false，则抛弃参考数据集，只返回 结果数据集。

# 专用过滤器

专用过滤器通常直接继承自 FilterBase，用于更特定的场景。

# 单列列值过滤器 (SingleColumnValueFilter)

基于某列（参考列）的值决定某行数据是否被过滤。其实例有以下方法：

  • setFilterIfMissing(boolean filterIfMissing) ：默认值为 false，即如果该行数据不包含参考列，其依然被包含在最后的结果中；设置为 true 时，则不包含；
  • setLatestVersionOnly(boolean latestVersionOnly) ：默认为 true，即只检索参考列的最新版本数据；设置为 false，则检索所有版本数据。
SingleColumnValueFilter singleColumnValueFilter = new SingleColumnValueFilter(
+                "student".getBytes(),
+                "name".getBytes(),
+                CompareOperator.EQUAL,
+                new SubstringComparator("xiaolan"));
+singleColumnValueFilter.setFilterIfMissing(true);
+scan.setFilter(singleColumnValueFilter);
+

# 单列列值排除器 (SingleColumnValueExcludeFilter)

SingleColumnValueExcludeFilter 继承自上面的 SingleColumnValueFilter，过滤行为与其相反。

# 行键前缀过滤器 (PrefixFilter)

基于 RowKey 值决定某行数据是否被过滤。

PrefixFilter prefixFilter = new PrefixFilter(Bytes.toBytes("xxx"));
+scan.setFilter(prefixFilter);
+

# 列名前缀过滤器 (ColumnPrefixFilter)

基于列限定符（列名）决定某行数据是否被过滤。

ColumnPrefixFilter columnPrefixFilter = new ColumnPrefixFilter(Bytes.toBytes("xxx"));
+ scan.setFilter(columnPrefixFilter);
+

# 分页过滤器 (PageFilter)

可以使用这个过滤器实现对结果按行进行分页，创建 PageFilter 实例的时候需要传入每页的行数。

public PageFilter(final long pageSize) {
+    Preconditions.checkArgument(pageSize >= 0, "must be positive %s", pageSize);
+    this.pageSize = pageSize;
+  }
+

下面的代码体现了客户端实现分页查询的主要逻辑，这里对其进行一下解释说明：

客户端进行分页查询，需要传递 startRow(起始 RowKey)，知道起始 startRow 后，就可以返回对应的 pageSize 行数据。这里唯一的问题就是，对于第一次查询，显然 startRow 就是表格的第一行数据，但是之后第二次、第三次查询我们并不知道 startRow，只能知道上一次查询的最后一条数据的 RowKey（简单称之为 lastRow）。

我们不能将 lastRow 作为新一次查询的 startRow 传入，因为 scan 的查询区间是[startRow，endRow) ，即前开后闭区间，这样 startRow 在新的查询也会被返回，这条数据就重复了。

同时在不使用第三方数据库存储 RowKey 的情况下，我们是无法通过知道 lastRow 的下一个 RowKey 的，因为 RowKey 的设计可能是连续的也有可能是不连续的。

由于 Hbase 的 RowKey 是按照字典序进行排序的。这种情况下，就可以在 lastRow 后面加上 0 ，作为 startRow 传入，因为按照字典序的规则，某个值加上 0 后的新值，在字典序上一定是这个值的下一个值，对于 HBase 来说下一个 RowKey 在字典序上一定也是等于或者大于这个新值的。

所以最后传入 lastRow+0，如果等于这个值的 RowKey 存在就从这个值开始 scan,否则从字典序的下一个 RowKey 开始 scan。

25 个字母以及数字字符，字典排序如下:

'0' < '1' < '2' < ... < '9' < 'a' < 'b' < ... < 'z'
+

分页查询主要实现逻辑：

byte[] POSTFIX = new byte[] { 0x00 };
+Filter filter = new PageFilter(15);
+
+int totalRows = 0;
+byte[] lastRow = null;
+while (true) {
+    Scan scan = new Scan();
+    scan.setFilter(filter);
+    if (lastRow != null) {
+        // 如果不是首行 则 lastRow + 0
+        byte[] startRow = Bytes.add(lastRow, POSTFIX);
+        System.out.println("start row: " +
+                           Bytes.toStringBinary(startRow));
+        scan.withStartRow(startRow);
+    }
+    ResultScanner scanner = table.getScanner(scan);
+    int localRows = 0;
+    Result result;
+    while ((result = scanner.next()) != null) {
+        System.out.println(localRows++ + ": " + result);
+        totalRows++;
+        lastRow = result.getRow();
+    }
+    scanner.close();
+    //最后一页，查询结束
+    if (localRows == 0) break;
+}
+System.out.println("total rows: " + totalRows);
+

需要注意的是在多台 Regin Services 上执行分页过滤的时候，由于并行执行的过滤器不能共享它们的状态和边界，所以有可能每个过滤器都会在完成扫描前获取了 PageCount 行的结果，这种情况下会返回比分页条数更多的数据，分页过滤器就有失效的可能。

# 时间戳过滤器 (TimestampsFilter)

List<Long> list = new ArrayList<>();
+list.add(1554975573000L);
+TimestampsFilter timestampsFilter = new TimestampsFilter(list);
+scan.setFilter(timestampsFilter);
+

# 首次行键过滤器 (FirstKeyOnlyFilter)

FirstKeyOnlyFilter 只扫描每行的第一列，扫描完第一列后就结束对当前行的扫描，并跳转到下一行。相比于全表扫描，其性能更好，通常用于行数统计的场景，因为如果某一行存在，则行中必然至少有一列。

FirstKeyOnlyFilter firstKeyOnlyFilter = new FirstKeyOnlyFilter();
+scan.set(firstKeyOnlyFilter);
+

# 包装过滤器

包装过滤器就是通过包装其他过滤器以实现某些拓展的功能。

# SkipFilter 过滤器

SkipFilter 包装一个过滤器，当被包装的过滤器遇到一个需要过滤的 KeyValue 实例时，则拓展过滤整行数据。下面是一个使用示例：

// 定义 ValueFilter 过滤器
+Filter filter1 = new ValueFilter(CompareOperator.NOT_EQUAL,
+      new BinaryComparator(Bytes.toBytes("xxx")));
+// 使用 SkipFilter 进行包装
+Filter filter2 = new SkipFilter(filter1);
+

# WhileMatchFilter 过滤器

WhileMatchFilter 包装一个过滤器，当被包装的过滤器遇到一个需要过滤的 KeyValue 实例时，WhileMatchFilter 则结束本次扫描，返回已经扫描到的结果。下面是其使用示例：

Filter filter1 = new RowFilter(CompareOperator.NOT_EQUAL,
+                               new BinaryComparator(Bytes.toBytes("rowKey4")));
+
+Scan scan = new Scan();
+scan.setFilter(filter1);
+ResultScanner scanner1 = table.getScanner(scan);
+for (Result result : scanner1) {
+    for (Cell cell : result.listCells()) {
+        System.out.println(cell);
+    }
+}
+scanner1.close();
+
+System.out.println("--------------------");
+
+// 使用 WhileMatchFilter 进行包装
+Filter filter2 = new WhileMatchFilter(filter1);
+
+scan.setFilter(filter2);
+ResultScanner scanner2 = table.getScanner(scan);
+for (Result result : scanner1) {
+    for (Cell cell : result.listCells()) {
+        System.out.println(cell);
+    }
+}
+scanner2.close();
+rowKey0/student:name/1555035006994/Put/vlen=8/seqid=0
+rowKey1/student:name/1555035007019/Put/vlen=8/seqid=0
+rowKey2/student:name/1555035007025/Put/vlen=8/seqid=0
+rowKey3/student:name/1555035007037/Put/vlen=8/seqid=0
+rowKey5/student:name/1555035007051/Put/vlen=8/seqid=0
+rowKey6/student:name/1555035007057/Put/vlen=8/seqid=0
+rowKey7/student:name/1555035007062/Put/vlen=8/seqid=0
+rowKey8/student:name/1555035007068/Put/vlen=8/seqid=0
+rowKey9/student:name/1555035007073/Put/vlen=8/seqid=0
+--------------------
+rowKey0/student:name/1555035006994/Put/vlen=8/seqid=0
+rowKey1/student:name/1555035007019/Put/vlen=8/seqid=0
+rowKey2/student:name/1555035007025/Put/vlen=8/seqid=0
+rowKey3/student:name/1555035007037/Put/vlen=8/seqid=0
+

可以看到被包装后，只返回了 rowKey4 之前的数据。

# FilterList

以上都是讲解单个过滤器的作用，当需要多个过滤器共同作用于一次查询的时候，就需要使用 FilterList。FilterList 支持通过构造器或者 addFilter 方法传入多个过滤器。

// 构造器传入
+public FilterList(final Operator operator, final List<Filter> filters)
+public FilterList(final List<Filter> filters)
+public FilterList(final Filter... filters)
+
+// 方法传入
+ public void addFilter(List<Filter> filters)
+ public void addFilter(Filter filter)
+

多个过滤器组合的结果由 operator 参数定义 ，其可选参数定义在 Operator 枚举类中。只有 MUST_PASS_ALL 和 MUST_PASS_ONE 两个可选的值：

  • MUST_PASS_ALL ：相当于 AND，必须所有的过滤器都通过才认为通过；
  • MUST_PASS_ONE ：相当于 OR，只有要一个过滤器通过则认为通过。
@InterfaceAudience.Public
+  public enum Operator {
+    /** !AND */
+    MUST_PASS_ALL,
+    /** !OR */
+    MUST_PASS_ONE
+  }
+

使用示例如下：

List<Filter> filters = new ArrayList<Filter>();
+
+Filter filter1 = new RowFilter(CompareOperator.GREATER_OR_EQUAL,
+                               new BinaryComparator(Bytes.toBytes("XXX")));
+filters.add(filter1);
+
+Filter filter2 = new RowFilter(CompareOperator.LESS_OR_EQUAL,
+                               new BinaryComparator(Bytes.toBytes("YYY")));
+filters.add(filter2);
+
+Filter filter3 = new QualifierFilter(CompareOperator.EQUAL,
+                                     new RegexStringComparator("ZZZ"));
+filters.add(filter3);
+
+FilterList filterList = new FilterList(filters);
+
+Scan scan = new Scan();
+scan.setFilter(filterList);
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#大数据#HBase#API
上次更新: 2023/06/29, 22:27:04
HBase Java API 基础特性
HBase Java API 高级特性之协处理器

+ ← + HBase Java API 高级特性之协处理器→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/a5a001/index.html b/pages/a5a001/index.html new file mode 100644 index 00000000..9c86fd5c --- /dev/null +++ b/pages/a5a001/index.html @@ -0,0 +1,228 @@ + + + + + + Elasticsearch 分析器 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-02-22
目录

Elasticsearch 分析器

# Elasticsearch 分析器

文本分析是把全文本转换为一系列单词（term/token）的过程，也叫分词。在 Elasticsearch 中，分词是通过 analyzer（分析器）来完成的，不管是索引还是搜索，都需要使用 analyzer（分析器）。分析器，分为内置分析器和自定义的分析器。

分析器可以进一步细分为字符过滤器（Character Filters）、分词器（Tokenizer）和词元过滤器（Token Filters）三部分。它的执行顺序如下：

character filters -> tokenizer -> token filters

# 字符过滤器（Character Filters）

character filter 的输入是原始的文本 text，如果配置了多个，它会按照配置的顺序执行，目前 ES 自带的 character filter 主要有如下 3 类：

  1. html strip character filter：从文本中剥离 HTML 元素，并用其解码值替换 HTML 实体（如，将 ＆amp; 替换为 ＆）。
  2. mapping character filter：自定义一个 map 映射，可以进行一些自定义的替换，如常用的大写变小写也可以在该环节设置。
  3. pattern replace character filter：使用 java 正则表达式来匹配应替换为指定替换字符串的字符，此外，替换字符串可以引用正则表达式中的捕获组。

# HTML strip character filter

HTML strip 如下示例：

GET /_analyze
+{
+  "tokenizer": "keyword",
+  "char_filter": [
+    "html_strip"
+  ],
+  "text": "<p>I&apos;m so <b>happy</b>!</p>"
+}
+

经过 html_strip 字符过滤器处理后，输出如下：

[ \nI'm so happy!\n ]
+

# Mapping character filter

Mapping character filter 接收键和值映射（key => value）作为配置参数，每当在预处理过程中遇到与键值映射中的键相同的字符串时，就会使用该键对应的值去替换它。

原始文本中的字符串和键值映射中的键的匹配是贪心的，在对给定的文本进行预处理过程中如果配置的键值映射存在包含关系，会优先匹配最长键。同样也可以用空字符串进行替换。

mapping char_filter 不像 html_strip 那样拆箱即可用，必须先进行配置才能使用，它有两个属性可以配置：

参数名称 参数说明
mappings 一组映射，每个元素的格式为 key => value。
mappings_path 一个相对或者绝对的文件路径，指向一个每行包含一个 key =>value 映射的 UTF-8 编码文本映射文件。

mapping char_filter 示例如下：

GET /_analyze
+{
+  "tokenizer": "keyword",
+  "char_filter": [
+    {
+      "type": "mapping",
+      "mappings": [
+        "٠ => 0",
+        "١ => 1",
+        "٢ => 2",
+        "٣ => 3",
+        "٤ => 4",
+        "٥ => 5",
+        "٦ => 6",
+        "٧ => 7",
+        "٨ => 8",
+        "٩ => 9"
+      ]
+    }
+  ],
+  "text": "My license plate is ٢٥٠١٥"
+}
+

分析结果如下：

[ My license plate is 25015 ]
+

# Pattern Replace character filter

Pattern Replace character filter 支持如下三个参数：

参数名称 参数说明
pattern 必填参数，一个 java 的正则表达式。
replacement 替换字符串，可以使用 $1 ... $9 语法来引用捕获组。
flags Java 正则表达式的标志，具体参考 java 的 java.util.regex.Pattern 类的标志属性。

如将输入的 text 中大于一个的空格都转变为一个空格，在 settings 时，配置示例如下：

"char_filter": {
+  "multi_space_2_one": {
+    "pattern": "[ ]+",
+    "type": "pattern_replace",
+    "replacement": " "
+  },
+  ...
+}
+

# 分词器（Tokenizer）

tokenizer 即分词器，也是 analyzer 最重要的组件，它对文本进行分词；一个 analyzer 必需且只可包含一个 tokenizer。

ES 自带默认的分词器是 standard tokenizer，标准分词器提供基于语法的分词（基于 Unicode 文本分割算法），并且适用于大多数语言。

此外有很多第三方的分词插件，如中文分词界最经典的 ik 分词器，它对应的 tokenizer 分为 ik_smart 和 ik_max_word，一个是智能分词（针对搜索侧），一个是全切分词（针对索引侧）。

ES 默认提供的分词器 standard 对中文分词不优化，效果差，一般会安装第三方中文分词插件，通常首先 elasticsearch-analysis-ik (opens new window) 插件，它其实是 ik 针对的 ES 的定制版。

# elasticsearch-plugin 使用

在安装 elasticsearch-analysis-ik 第三方之前，我们首先要了解 es 的插件管理工具 elasticsearch-plugin 的使用。

现在的 elasticsearch 安装完后，在安装目录的 bin 目录下会存在 elasticsearch-plugin 命令工具，用它来对 es 插件进行管理。

bin/elasticsearch-plugin
+

其实该命令的是软连接，原始路径是：

libexec/bin/elasticsearch-plugin
+

再进一步看脚本代码，你会发现，它是通过 elasticsearch-cli 执行 libexec/lib/tools/plugin-cli/elasticsearch-plugin-cli-x.x.x.jar。

但一般使用者了解 elasticsearch-plugin 命令使用就可：

#  安装指定的插件到当前 ES 节点中
+elasticsearch-plugin install {plugin_url}
+
+#  显示当前 ES 节点已经安装的插件列表
+elasticsearch-plugin list
+
+#  删除已安装的插件
+elasticsearch-plugin remove {plugin_name}
+

在安装插件时，要保证安装的插件与 ES 版本一致。

# elasticsearch-analysis-ik 安装

在确定要安装的 ik 版本之后，执行如下命令：

./bin/elasticsearch-plugin install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v{X.X.X}/elasticsearch-analysis-ik-{X.X.X}.zip
+

执行完安装命令后，我们会发现在 plugins 中多了 analysis-ik 目录，这里面主要存放的是源码 jar 包，此外，在 config 文件里也多了 analysis-ik 目录，里面主要是 ik 相关的配置，如 IKAnalyzer.cfg.xml 配置、词典文件等。

#  两个新增目录路径
+libexec/plugins/analysis-ik/
+libexec/config/analysis-ik/
+

# elasticsearch-analysis-ik 使用

ES 5.X 版本开始安装完的 elasticsearch-analysis-ik 提供了两个分词器，分别对应名称是 ik_max_word 和 ik_smart，ik_max_word 是索引侧的分词器，走全切模式，ik_smart 是搜索侧的分词器，走智能分词，属于搜索模式。

# 索引 mapping 设置

安装完 elasticsearch-analysis-ik 后，我们可以指定索引及指定字段设置可用的分析器（analyzer），示例如下：

{
+  "qa": {
+    "mappings": {
+      "qa": {
+        "_all": {
+          "enabled": false
+        },
+        "properties": {
+          "question": {
+            "type": "text",
+            "store": true,
+            "similarity": "BM25",
+            "analyzer": "ik_max_word",
+            "search_analyzer": "ik_smart"
+          },
+          "answer": {
+            "type": "text",
+            "store": false,
+            "similarity": "BM25",
+            "analyzer": "ik_max_word",
+            "search_analyzer": "ik_smart"
+          },
+          ...
+        }
+      }
+    }
+  }
+}
+

如上示例中，analyzer 指定 ik_max_word，即索引侧使用 ik 全切模式，search_analyzer 设置 ik_smart，即搜索侧使用 ik 智能分词模式。

# 查看 ik 分词结果

es 提供了查看分词结果的 api analyze，具体示例如下：

GET {index}/_analyze
+{
+  "analyzer" : "ik_smart",
+  "text" : "es 中文分词器安装"
+}
+

输出如下：

{
+  "tokens": [
+    {
+      "token": "es",
+      "start_offset": 0,
+      "end_offset": 2,
+      "type": "CN_WORD",
+      "position": 0
+    },
+    {
+      "token": "中文",
+      "start_offset": 3,
+      "end_offset": 5,
+      "type": "CN_WORD",
+      "position": 1
+    },
+    {
+      "token": "分词器",
+      "start_offset": 5,
+      "end_offset": 8,
+      "type": "CN_WORD",
+      "position": 2
+    },
+    {
+      "token": "安装",
+      "start_offset": 8,
+      "end_offset": 10,
+      "type": "CN_WORD",
+      "position": 3
+    }
+  ]
+}
+

# elasticsearch-analysis-ik 自定义词典

elasticsearch-analysis-ik 本质是 ik 分词器，使用者根据实际需求可以扩展自定义的词典，具体主要分为如下 2 大类，每类又分为本地配置和远程配置 2 种：

  1. 自定义扩展词典；
  2. 自定义扩展停用词典；

elasticsearch-analysis-ik 配置文件为 IKAnalyzer.cfg.xml，它位于 libexec/config/analysis-ik 目录下，具体配置结构如下：

<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
+<properties>
+	<comment>IK Analyzer 扩展配置</comment>
+	<!--用户可以在这里配置自己的扩展字典 -->
+	<entry key="ext_dict"></entry>
+	 <!--用户可以在这里配置自己的扩展停止词字典-->
+	<entry key="ext_stopwords"></entry>
+	<!--用户可以在这里配置远程扩展字典 -->
+	<!-- <entry key="remote_ext_dict">words_location</entry> -->
+	<!--用户可以在这里配置远程扩展停止词字典-->
+	<!-- <entry key="remote_ext_stopwords">words_location</entry> -->
+</properties>
+

当然，如果开发者认为 ik 默认的词表有问题，也可以进行调整，文件都在 libexec/config/analysis-ik 下，如 main.dic 为主词典，stopword.dic 为停用词表。

# 词元过滤器（Token Filters）

token filters 叫词元过滤器，或词项过滤器，对 tokenizer 分出的词进行过滤处理。常用的有转小写、停用词处理、同义词处理等等。一个 analyzer 可包含 0 个或多个词项过滤器，按配置顺序进行过滤。

以同义词过滤器的使用示例，具体如下：

PUT /test_index
+{
+  "settings": {
+    "index": {
+      "analysis": {
+        "analyzer": {
+          "synonym": {
+            "tokenizer": "standard",
+            "filter": [ "my_stop", "synonym" ]
+          }
+        },
+        "filter": {
+          "my_stop": {
+            "type": "stop",
+            "stopwords": [ "bar" ]
+          },
+          "synonym": {
+            "type": "synonym",
+            "lenient": true,
+            "synonyms": [ "foo, bar => baz" ]
+          }
+        }
+      }
+    }
+  }
+}
+

# 同义词

Elasticsearch 同义词通过专有的同义词过滤器（synonym token filter）来进行工作，它允许在分析（analysis）过程中方便地处理同义词，一般是通过配置文件配置同义词。此外，同义词可以再建索引时（index-time synonyms）或者检索时（search-time synonyms）使用。

# 同义词（synonym）配置语法

如上例子所示，es 同义词配置的 filter 语法具体如下选项：

  • type：指定 synonym，表示同义词 filter；

  • synonyms_path：指定同义词配置文件路径；

  • expand：该参数决定映射行为的模式，默认为 true，表示扩展模式，具体示例如下：

    • 当 expand == true 时，

      ipod, i-pod, i pod
+

      等价于：

      ipod, i-pod, i pod => ipod, i-pod, i pod
+

      当 expand == false 时，

      ipod, i-pod, i pod
+

      仅映射第一个单词，等价于：

      ipod, i-pod, i pod => ipod
+

  • lenient：如果值为 true 时，遇到那些无法解析的同义词规则时，忽略异常。默认为 false。

# 同义词文档格式

elasticsearch 的同义词有如下两种形式：

  • 单向同义词：

    ipod, i-pod, i pod => ipod
+

  • 双向同义词：

    马铃薯, 土豆, potato
+

单向同义词不管索引还是检索时，箭头左侧的词都会映射成箭头右侧的词；

双向同义词是索引时，都建立同义词的倒排索引，检索时，同义词之间都会进行倒排索引的匹配。

同义词的文档化时，需要注意的是，同一个词在不同的同义词关系中出现时，其它同义词之间不具有传递性，这点需要注意。

假设如上示例中，如果“马铃薯”和其它两个同义词分成两行写：

马铃薯,土豆
+马铃薯,potato
+

此时，elasticsearch 中不会将“土豆”和“potato”视为同义词关系，所以多个同义词要写在一起，这往往是开发中经常容易疏忽的点。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#分词
上次更新: 2023/06/29, 22:27:04
Elasticsearch 聚合
Elasticsearch 性能优化

+ ← + Elasticsearch 性能优化→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/a5b63b/index.html b/pages/a5b63b/index.html new file mode 100644 index 00000000..3b88f79d --- /dev/null +++ b/pages/a5b63b/index.html @@ -0,0 +1,59 @@ + + + + + + Mysql 教程 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-02-10
目录

Mysql 教程

# Mysql 教程

img

# 📖 内容

# Mysql 应用指南

# Mysql 工作流

# Mysql 事务

关键词：ACID、AUTOCOMMIT、事务隔离级别、死锁、分布式事务

img

# Mysql 锁

关键词：乐观锁、表级锁、行级锁、意向锁、MVCC、Next-key 锁

img

# Mysql 索引

关键词：Hash、B 树、聚簇索引、回表

img

# Mysql 性能优化

# Mysql 运维 🔨

# Mysql 配置 🔨

# Mysql 常见问题

# 📚 资料

# 🚪 传送

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#Mysql
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/a69528/index.html b/pages/a69528/index.html new file mode 100644 index 00000000..bf900556 --- /dev/null +++ b/pages/a69528/index.html @@ -0,0 +1,85 @@ + + + + + + HBase Schema 设计 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2023-03-15
目录

HBase Schema 设计

# HBase Schema 设计

# HBase Schema 设计要素

  • 这个表应该有多少 Column Family
  • Column Family 使用什么数据
  • 每个 Column Family 有有多少列
  • 列名是什么，尽管列名不必在建表时定义，但读写数据是要知道的
  • 单元应该存放什么数据
  • 每个单元存储多少时间版本
  • 行健(rowKey)结构是什么，应该包含什么信息

# Row Key 设计

# Row Key 的作用

在 HBase 中，所有对表的访问都要通过 Row Key，有三种访问方式：

  • 使用 get 命令，查询指定的 Row Key，即精确查找。
  • 使用 scan 命令，根据 Row Key 进行范围查找。
  • 全表扫描，即直接扫描表中所有行记录。

此外，在 HBase 中，表中的行，是按照 Row Key 的字典序进行排序的。

由此，可见，Row Key 的良好设计对于 HBase CRUD 的性能至关重要。

# Row Key 的设计原则

长度原则

RowKey 是一个二进制码流，可以是任意字符串，最大长度为 64kb，实际应用中一般为 10-100byte，以 byte[]形式保存，一般设计成定长。建议越短越好，不要超过 16 个字节，原因如下：

  1. 数据的持久化文件 HFile 中时按照 Key-Value 存储的，如果 RowKey 过长，例如超过 100byte，那么 1000w 行的记录，仅 RowKey 就需占用近 1GB 的空间。这样会极大影响 HFile 的存储效率。
  2. MemStore 会缓存部分数据到内存中，若 RowKey 字段过长，内存的有效利用率就会降低，就不能缓存更多的数据，从而降低检索效率。
  3. 目前操作系统都是 64 位系统，内存 8 字节对齐，控制在 16 字节，8 字节的整数倍利用了操作系统的最佳特性。

唯一原则

必须在设计上保证 RowKey 的唯一性。由于在 HBase 中数据存储是 Key-Value 形式，若向 HBase 中同一张表插入相同 RowKey 的数据，则原先存在的数据会被新的数据覆盖。

排序原则

HBase 的 RowKey 是按照 ASCII 有序排序的，因此我们在设计 RowKey 的时候要充分利用这点。

散列原则

设计的 RowKey 应均匀的分布在各个 HBase 节点上。

# 热点问题

Region 是在 HBase 集群上分布数据的最小单位。每个 Region 由它所属的表的起始范围来表示（即起始 Row Key 和结束 Row Key）。

如果，Row Key 使用单调递增的整数或时间戳，就会产生一个问题：因为 Hbase 的 Row Key 是就近存储的，这会导致一段时间内大部分读写集中在某一个 Region 或少数 Region 上（根据二八原则，最近产生的数据，往往是读写频率最高的数据），即所谓 热点问题。

# 反转（Reversing）

第一种咱们要分析的方法是反转，顾名思义它就是把固定长度或者数字格式的 RowKey 进行反转，反转分为一般数据反转和时间戳反转，其中以时间戳反转较常见。

  • 反转固定格式的数值 - 以手机号为例，手机号的前缀变化比较少（如 152、185 等），但后半部分变化很多。如果将它反转过来，可以有效地避免热点。不过其缺点就是失去了有序性。
  • 反转时间 - 如果数据访问以查找最近的数据为主，可以将时间戳存储为反向时间戳（例如： timestamp = Long.MAX_VALUE – timestamp），这样有利于扫描最近的数据。

# 加盐（Salting）

这里的“加盐”与密码学中的“加盐”不是一回事。它是指在 RowKey 的前面增加一些前缀，加盐的前缀种类越多，RowKey 就被打得越散。

需要注意的是分配的随机前缀的种类数量应该和我们想把数据分散到的那些 region 的数量一致。只有这样，加盐之后的 rowkey 才会根据随机生成的前缀分散到各个 region 中，避免了热点现象。

# 哈希（Hashing）

其实哈希和加盐的适用场景类似，但我们前缀不可以是随机的，因为必须要让客户端能够完整地重构 RowKey。所以一般会拿原 RowKey 或其一部分计算 Hash 值，然后再对 Hash 值做运算作为前缀。

# HBase Schema 设计规则

# Column Family 设计

HBase 不能很好处理 2 ~ 3 个以上的 Column Family，所以 HBase 表应尽可能减少 Column Family 数。如果可以，请只使用一个列族，只有需要经常执行 Column 范围查询时，才引入多列族。也就是说，尽量避免同时查询多个列族。

  • Column Family 数量多，会影响数据刷新。HBase 的数据刷新是在每个 Region 的基础上完成的。因此，如果一个 Column Family 携带大量导致刷新的数据，那么相邻的列族即使携带的数据量很小，也会被刷新。当存在许多 Column Family 时，刷新交互会导致一堆不必要的 IO。 此外，在表/区域级别的压缩操作也会在每个存储中发生。
  • Column Family 数量多，会影响查找效率。如：Column Family A 有 100 万行，Column Family B 有 10 亿行，那么 Column Family A 的数据可能会分布在很多很多区域（和 RegionServers）。 这会降低 Column Family A 的批量扫描效率。

Column Family 名尽量简短，最好是一个字符。Column Family 会在列限定符中被频繁使用，缩短长度有利于节省空间并提升效率。

# Row 设计

HBase 中的 Row 按 Row Key 的字典顺序排序。

  • 不要将 Row Key 设计为单调递增的，例如：递增的整数或时间戳

    • 问题：因为 Hbase 的 Row Key 是就近存储的，这样会导致一段时间内大部分写入集中在某一个 Region 上，即所谓热点问题。

    • 解决方法一、加盐：这里的不是指密码学的加盐，而是指将随机分配的前缀添加到行键的开头。这么做是为了避免相同前缀的 Row Key 数据被存储在相邻位置，从而导致热点问题。示例如下：

      • foo0001
+foo0002
+foo0003
+foo0004
+
+改为
+
+a-foo0003
+b-foo0001
+c-foo0003
+c-foo0004
+d-foo0002
+

    • 解决方法二、Hash：Row Key 的前缀使用 Hash

  • 尽量减少行和列的长度

  • 反向时间戳：反向时间戳可以极大地帮助快速找到值的最新版本。

  • 行健不能改变：唯一可以改变的方式是先删除后插入。

  • Row Key 和 Column Family：Row Key 从属于 Column Family，因此，相同的 Row Key 可以存在每一个 Column Family 中而不会出现冲突。

# Version 设计

最大、最小 Row 版本号：表示 HBase 会保留的版本号数的上下限。均可以通过 HColumnDescriptor 对每个列族进行配置

Row 版本号过大，会大大增加 StoreFile 的大小；所以，最大 Row 版本号应按需设置。HBase 会在主要压缩时，删除多余的版本。

# TTL 设计

Column Family 会设置一个以秒为单位的 TTL，一旦达到 TTL 时，HBase 会自动删除行记录。

仅包含过期行的存储文件在次要压缩时被删除。 将 hbase.store.delete.expired.storefile 设置为 false 会禁用此功能。将最小版本数设置为 0 以外的值也会禁用此功能。

在较新版本的 HBase 上，还支持在 Cell 上设置 TTL，与 Column Family 的 TTL 不同的是，单位是毫秒。

# Column Family 属性配置

  • HFile 数据块，默认是 64KB，数据库的大小影响数据块索引的大小。数据块大的话一次加载进内存的数据越多，扫描查询效果越好。但是数据块小的话，随机查询性能更好
> create 'mytable',{NAME => 'cf1', BLOCKSIZE => '65536'}
+复制代码
+
  • 数据块缓存，数据块缓存默认是打开的，如果一些比较少访问的数据可以选择关闭缓存
> create 'mytable',{NAME => 'cf1', BLOCKCACHE => 'FALSE'}
+复制代码
+
  • 数据压缩，压缩会提高磁盘利用率，但是会增加 CPU 的负载，看情况进行控制
> create 'mytable',{NAME => 'cf1', COMPRESSION => 'SNAPPY'}
+复制代码
+

Hbase 表设计是和需求相关的，但是遵守表设计的一些硬性指标对性能的提升还是很有帮助的，这里整理了一些设计时用到的要点。

# Schema 设计案例

# 案例：日志数据和时序数据

假设采集以下数据

  • Hostname
  • Timestamp
  • Log event
  • Value/message

应该如何设计 Row Key？

（1）Timestamp 在 Row Key 头部

如果 Row Key 设计为 [timestamp][hostname][log-event] 形式，会出现热点问题。

如果针对时间的扫描很重要，可以采用时间戳分桶策略，即

bucket = timestamp % bucketNum
+

计算出桶号后，将 Row Key 指定为：[bucket][timestamp][hostname][log-event]

如上所述，要为特定时间范围选择数据，需要对每个桶执行扫描。 例如，100 个桶将在键空间中提供广泛的分布，但需要 100 次扫描才能获取单个时间戳的数据，因此需要权衡取舍。

（2）Hostname 在 Row Key 头部

如果主机样本量很大，将 Row Key 设计为 [hostname][log-event][timestamp]，这样有利于扫描 hostname。

（3）Timestamp 还是反向 Timestamp

如果数据访问以查找最近的数据为主，可以将时间戳存储为反向时间戳（例如： timestamp = Long.MAX_VALUE – timestamp），这样有利于扫描最近的数据。

（4）Row Key 是可变长度还是固定长度

拼接 Row Key 的关键字长度不一定是固定的，例如 hostname 有可能很长，也有可能很短。如果想要统一长度，可以参考以下做法：

  • 将关键字 Hash 编码：使用某种 Hash 算法计算关键字，并取固定长度的值（例如：8 位或 16 位）。
  • 使用数字替代关键字：例如：使用事件类型 Code 替换事件类型；hostname 如果是 IP，可以转换为 long
  • 截取关键字：截取后的关键字需要有足够的辨识度，长度大小根据具体情况权衡。

（5）时间分片

[hostname][log-event][timestamp1]
+[hostname][log-event][timestamp2]
+[hostname][log-event][timestamp3]
+

上面的例子中，每个详细事件都有单独的行键，可以重写如下，即每个时间段存储一次：

[hostname][log-event][timerange]
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#大数据#HBase
上次更新: 2023/06/29, 22:27:04
HBase 数据模型
HBase 架构

+ ← + HBase 架构→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/a8cad3/index.html b/pages/a8cad3/index.html new file mode 100644 index 00000000..3779bbba --- /dev/null +++ b/pages/a8cad3/index.html @@ -0,0 +1,399 @@ + + + + + + HBase Java API 基础特性 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2023-03-15
目录

HBase Java API 基础特性

# HBase Java API 基础特性

# HBase Client API

# HBase Java API 示例

引入依赖

<dependency>
+    <groupId>org.apache.hbase</groupId>
+    <artifactId>hbase-client</artifactId>
+    <version>2.1.4</version>
+</dependency>
+

示例

public class HBaseUtils {
+
+    private static Connection connection;
+
+    static {
+        Configuration configuration = HBaseConfiguration.create();
+        configuration.set("hbase.zookeeper.property.clientPort", "2181");
+        // 如果是集群 则主机名用逗号分隔
+        configuration.set("hbase.zookeeper.quorum", "hadoop001");
+        try {
+            connection = ConnectionFactory.createConnection(configuration);
+        } catch (IOException e) {
+            e.printStackTrace();
+        }
+    }
+
+    /**
+     * 创建 HBase 表
+     *
+     * @param tableName      表名
+     * @param columnFamilies 列族的数组
+     */
+    public static boolean createTable(String tableName, List<String> columnFamilies) {
+        try {
+            HBaseAdmin admin = (HBaseAdmin) connection.getAdmin();
+            if (admin.tableExists(TableName.valueOf(tableName))) {
+                return false;
+            }
+            TableDescriptorBuilder tableDescriptor = TableDescriptorBuilder.newBuilder(TableName.valueOf(tableName));
+            columnFamilies.forEach(columnFamily -> {
+                ColumnFamilyDescriptorBuilder cfDescriptorBuilder = ColumnFamilyDescriptorBuilder.newBuilder(Bytes.toBytes(columnFamily));
+                cfDescriptorBuilder.setMaxVersions(1);
+                ColumnFamilyDescriptor familyDescriptor = cfDescriptorBuilder.build();
+                tableDescriptor.setColumnFamily(familyDescriptor);
+            });
+            admin.createTable(tableDescriptor.build());
+        } catch (IOException e) {
+            e.printStackTrace();
+        }
+        return true;
+    }
+
+
+    /**
+     * 删除 hBase 表
+     *
+     * @param tableName 表名
+     */
+    public static boolean deleteTable(String tableName) {
+        try {
+            HBaseAdmin admin = (HBaseAdmin) connection.getAdmin();
+            // 删除表前需要先禁用表
+            admin.disableTable(TableName.valueOf(tableName));
+            admin.deleteTable(TableName.valueOf(tableName));
+        } catch (Exception e) {
+            e.printStackTrace();
+        }
+        return true;
+    }
+
+    /**
+     * 插入数据
+     *
+     * @param tableName        表名
+     * @param rowKey           唯一标识
+     * @param columnFamilyName 列族名
+     * @param qualifier        列标识
+     * @param value            数据
+     */
+    public static boolean putRow(String tableName, String rowKey, String columnFamilyName, String qualifier,
+                                 String value) {
+        try {
+            Table table = connection.getTable(TableName.valueOf(tableName));
+            Put put = new Put(Bytes.toBytes(rowKey));
+            put.addColumn(Bytes.toBytes(columnFamilyName), Bytes.toBytes(qualifier), Bytes.toBytes(value));
+            table.put(put);
+            table.close();
+        } catch (IOException e) {
+            e.printStackTrace();
+        }
+        return true;
+    }
+
+
+    /**
+     * 插入数据
+     *
+     * @param tableName        表名
+     * @param rowKey           唯一标识
+     * @param columnFamilyName 列族名
+     * @param pairList         列标识和值的集合
+     */
+    public static boolean putRow(String tableName, String rowKey, String columnFamilyName, List<Pair<String, String>> pairList) {
+        try {
+            Table table = connection.getTable(TableName.valueOf(tableName));
+            Put put = new Put(Bytes.toBytes(rowKey));
+            pairList.forEach(pair -> put.addColumn(Bytes.toBytes(columnFamilyName), Bytes.toBytes(pair.getKey()), Bytes.toBytes(pair.getValue())));
+            table.put(put);
+            table.close();
+        } catch (IOException e) {
+            e.printStackTrace();
+        }
+        return true;
+    }
+
+
+    /**
+     * 根据 rowKey 获取指定行的数据
+     *
+     * @param tableName 表名
+     * @param rowKey    唯一标识
+     */
+    public static Result getRow(String tableName, String rowKey) {
+        try {
+            Table table = connection.getTable(TableName.valueOf(tableName));
+            Get get = new Get(Bytes.toBytes(rowKey));
+            return table.get(get);
+        } catch (IOException e) {
+            e.printStackTrace();
+        }
+        return null;
+    }
+
+
+    /**
+     * 获取指定行指定列 (cell) 的最新版本的数据
+     *
+     * @param tableName    表名
+     * @param rowKey       唯一标识
+     * @param columnFamily 列族
+     * @param qualifier    列标识
+     */
+    public static String getCell(String tableName, String rowKey, String columnFamily, String qualifier) {
+        try {
+            Table table = connection.getTable(TableName.valueOf(tableName));
+            Get get = new Get(Bytes.toBytes(rowKey));
+            if (!get.isCheckExistenceOnly()) {
+                get.addColumn(Bytes.toBytes(columnFamily), Bytes.toBytes(qualifier));
+                Result result = table.get(get);
+                byte[] resultValue = result.getValue(Bytes.toBytes(columnFamily), Bytes.toBytes(qualifier));
+                return Bytes.toString(resultValue);
+            } else {
+                return null;
+            }
+
+        } catch (IOException e) {
+            e.printStackTrace();
+        }
+        return null;
+    }
+
+
+    /**
+     * 检索全表
+     *
+     * @param tableName 表名
+     */
+    public static ResultScanner getScanner(String tableName) {
+        try {
+            Table table = connection.getTable(TableName.valueOf(tableName));
+            Scan scan = new Scan();
+            return table.getScanner(scan);
+        } catch (IOException e) {
+            e.printStackTrace();
+        }
+        return null;
+    }
+
+
+    /**
+     * 检索表中指定数据
+     *
+     * @param tableName  表名
+     * @param filterList 过滤器
+     */
+
+    public static ResultScanner getScanner(String tableName, FilterList filterList) {
+        try {
+            Table table = connection.getTable(TableName.valueOf(tableName));
+            Scan scan = new Scan();
+            scan.setFilter(filterList);
+            return table.getScanner(scan);
+        } catch (IOException e) {
+            e.printStackTrace();
+        }
+        return null;
+    }
+
+    /**
+     * 检索表中指定数据
+     *
+     * @param tableName   表名
+     * @param startRowKey 起始 RowKey
+     * @param endRowKey   终止 RowKey
+     * @param filterList  过滤器
+     */
+
+    public static ResultScanner getScanner(String tableName, String startRowKey, String endRowKey,
+                                           FilterList filterList) {
+        try {
+            Table table = connection.getTable(TableName.valueOf(tableName));
+            Scan scan = new Scan();
+            scan.withStartRow(Bytes.toBytes(startRowKey));
+            scan.withStopRow(Bytes.toBytes(endRowKey));
+            scan.setFilter(filterList);
+            return table.getScanner(scan);
+        } catch (IOException e) {
+            e.printStackTrace();
+        }
+        return null;
+    }
+
+    /**
+     * 删除指定行记录
+     *
+     * @param tableName 表名
+     * @param rowKey    唯一标识
+     */
+    public static boolean deleteRow(String tableName, String rowKey) {
+        try {
+            Table table = connection.getTable(TableName.valueOf(tableName));
+            Delete delete = new Delete(Bytes.toBytes(rowKey));
+            table.delete(delete);
+        } catch (IOException e) {
+            e.printStackTrace();
+        }
+        return true;
+    }
+
+
+    /**
+     * 删除指定行指定列
+     *
+     * @param tableName  表名
+     * @param rowKey     唯一标识
+     * @param familyName 列族
+     * @param qualifier  列标识
+     */
+    public static boolean deleteColumn(String tableName, String rowKey, String familyName,
+                                          String qualifier) {
+        try {
+            Table table = connection.getTable(TableName.valueOf(tableName));
+            Delete delete = new Delete(Bytes.toBytes(rowKey));
+            delete.addColumn(Bytes.toBytes(familyName), Bytes.toBytes(qualifier));
+            table.delete(delete);
+            table.close();
+        } catch (IOException e) {
+            e.printStackTrace();
+        }
+        return true;
+    }
+
+}
+

# 数据库连接

在上面的代码中，在类加载时就初始化了 Connection 连接，并且之后的方法都是复用这个 Connection，这时我们可能会考虑是否可以使用自定义连接池来获取更好的性能表现？实际上这是没有必要的。

首先官方对于 Connection 的使用说明如下：

Connection Pooling For applications which require high-end multithreaded
+access (e.g., web-servers or  application servers  that may serve many
+application threads in a single JVM), you can pre-create a Connection,
+as shown in the following example:
+
+对于高并发多线程访问的应用程序（例如，在单个 JVM 中存在的为多个线程服务的 Web 服务器或应用程序服务器），
+您只需要预先创建一个 Connection。例子如下：
+
+// Create a connection to the cluster.
+Configuration conf = HBaseConfiguration.create();
+try (Connection connection = ConnectionFactory.createConnection(conf);
+     Table table = connection.getTable(TableName.valueOf(tablename))) {
+  // use table as needed, the table returned is lightweight
+}
+

之所以能这样使用，这是因为 Connection 并不是一个简单的 socket 连接，接口文档 (opens new window) 中对 Connection 的表述是：

A cluster connection encapsulating lower level individual connections to actual servers and a
+connection to zookeeper.  Connections are instantiated through the ConnectionFactory class.
+The lifecycle of the connection is managed by the caller,  who has to close() the connection
+to release the resources.
+
+Connection 是一个集群连接，封装了与多台服务器（Matser/Region Server）的底层连接以及与 zookeeper 的连接。
+连接通过 ConnectionFactory  类实例化。连接的生命周期由调用者管理，调用者必须使用 close() 关闭连接以释放资源。
+

之所以封装这些连接，是因为 HBase 客户端需要连接三个不同的服务角色：

  • Zookeeper ：主要用于获取 meta 表的位置信息，Master 的信息；
  • HBase Master ：主要用于执行 HBaseAdmin 接口的一些操作，例如建表等；
  • HBase RegionServer ：用于读、写数据。

Connection 对象和实际的 Socket 连接之间的对应关系如下图：

在 HBase 客户端代码中，真正对应 Socket 连接的是 RpcConnection 对象。HBase 使用 PoolMap 这种数据结构来存储客户端到 HBase 服务器之间的连接。PoolMap 的内部有一个 ConcurrentHashMap 实例，其 key 是 ConnectionId(封装了服务器地址和用户 ticket)，value 是一个 RpcConnection 对象的资源池。当 HBase 需要连接一个服务器时，首先会根据 ConnectionId 找到对应的连接池，然后从连接池中取出一个连接对象。

@InterfaceAudience.Private
+public class PoolMap<K, V> implements Map<K, V> {
+  private PoolType poolType;
+
+  private int poolMaxSize;
+
+  private Map<K, Pool<V>> pools = new ConcurrentHashMap<>();
+
+  public PoolMap(PoolType poolType) {
+    this.poolType = poolType;
+  }
+  .....
+

HBase 中提供了三种资源池的实现，分别是 Reusable，RoundRobin 和 ThreadLocal。具体实现可以通 hbase.client.ipc.pool.type 配置项指定，默认为 Reusable。连接池的大小也可以通过 hbase.client.ipc.pool.size 配置项指定，默认为 1，即每个 Server 1 个连接。也可以通过修改配置实现：

config.set("hbase.client.ipc.pool.type",...);
+config.set("hbase.client.ipc.pool.size",...);
+connection = ConnectionFactory.createConnection(config);
+

由此可以看出 HBase 中 Connection 类已经实现了对连接的管理功能，所以我们不必在 Connection 上在做额外的管理。

另外，Connection 是线程安全的，但 Table 和 Admin 却不是线程安全的，因此正确的做法是一个进程共用一个 Connection 对象，而在不同的线程中使用单独的 Table 和 Admin 对象。Table 和 Admin 的获取操作 getTable() 和 getAdmin() 都是轻量级，所以不必担心性能的消耗，同时建议在使用完成后显示的调用 close() 方法来关闭它们。

# 概述

HBase 的主要客户端操作是由 org.apache.hadoop.hbase.client.HTable 提供的。创建 HTable 实例非常耗时，所以，建议每个线程只创建一次 HTable 实例。

HBase 所有修改数据的操作都保证了行级别的原子性。要么读到最新的修改，要么等待系统允许写入改行修改

用户要尽量使用批处理(batch)更新来减少单独操作同一行数据的次数

写操作中设计的列的数目并不会影响该行数据的原子性，行原子性会同时保护到所有列

创建 HTable 实例（指的是在 java 中新建该类），每个实例都要扫描.META. 表，以检查该表是否存在，推荐用户只创建一次 HTable 实例，而且是每个线程创建一个

如果用户需要多个 HTable 实例，建议使用 HTablePool 类（类似连接池）

# CRUD 操作

# put

Table 接口提供了两个 put 方法

// 写入单行 put
+void put(Put put) throws IOException;
+// 批量写入 put
+void put(List<Put> puts) throws IOException;
+

Put 类提供了多种构造器方法用来初始化实例。

Put 类还提供了一系列有用的方法：

多个 add 方法：用于添加指定的列数据。

has 方法：用于检查是否存在特定的单元格，而不需要遍历整个集合

getFamilyMap 方法：可以遍历 Put 实例中每一个可用的 KeyValue 实例

getRow 方法：用于获取 rowkey +Put.heapSize() 可以计算当前 Put 实例所需的堆大小，既包含其中的数据，也包含内部数据结构所需的空间

# KeyValue 类

特定单元格的数据以及坐标，坐标包括行键、列族名、列限定符以及时间戳 +KeyValue(byte[] row, int roffset, int rlength, byte[] family, int foffoset, int flength, byte[] qualifier, int qoffset, int qlength, long timestamp, Type type, byte[] value, int voffset, int vlength) +每一个字节数组都有一个 offset 参数和一个 length 参数，允许用户提交一个已经存在的字节数组进行字节级别操作。 +行目前来说指的是行键，即 Put 构造器里的 row 参数。

# 客户端的写缓冲区

每一个 put 操作实际上都是一个 RPC 操作，它将客户端数据传送到服务器然后返回。

HBase 的 API 配备了一个客户端的写缓冲区，缓冲区负责收集 put 操作，然后调用 RPC 操作一次性将 put 送往服务器。

void setAutoFlush(boolean autoFlush)
+boolean isAutoFlush()
+

默认情况下，客户端缓冲区是禁用的。可以通过 table.setAutoFlush(false) 来激活缓冲区。

# Put 列表

批量提交 put 列表：

void put(List<Put> puts) throws IOException
+

注意：批量提交可能会有部分修改失败。

# 原子性操作 compare-and-set

checkAndPut 方法提供了 CAS 机制来保证 put 操作的原子性。

# get

Result get(Get get) throws IOException
+
Get(byte[] row)
+Get(byte[] row, RowLock rowLock)
+Get addColumn(byte[] family, byte[] qualifier)
+Get addFamily(byte[] family)
+

# Result 类

当用户使用 get() 方法获取数据，HBase 返回的结果包含所有匹配的单元格数据，这些数据被封装在一个 Result 实例中返回给用户。

Result 类提供的方法如下：

byte[] getValue(byte[] family, byte[] qualifier)
+byte[] value()
+byte[] getRow()
+int size()
+boolean isEmpty()
+KeyValue[] raw()
+List<KeyValue> list()
+

# delete

void delete(Delete delete) throws IOException
+
Delte(byte[] row)
+Delete(byte[] row, long timestamp, RowLock rowLock)
+
Delete deleteFamily(byte[] family)
+Delete deleteFamily(byte[] family, long timestamp)
+Delete deleteColumns(byte[] family, byte[] qualifier)
+Delete deleteColumn(byte[] family, byte[] qualifier) // 只删除最新版本
+

# 批处理操作

Row 是 Put、Get、Delete 的父类。

void batch(List<Row> actions, Object[] results) throws IOException, InterruptedException
+Object batch(List<Row> actions) throws IOException, InterruptedException
+

# 行锁

region 服务器提供了行锁特性，这个特性保证了只有一个客户端能获取一行数据相应的锁，同时对该行进行修改。

如果不显示指定锁，服务器会隐式加锁。

# 扫描

scan，类似数据库系统中的 cursor，利用了 HBase 提供的底层顺序存储的数据结构。

调用 HTable 的 getScanner 就可以返回扫描器

ResultScanner getScanner(Scan scan) throws IOException
+ResultScanner getScanner(byte[] family) throws IOException
+

Scan 类构造器可以有 startRow，区间一般为 [startRow, stopRow)

Scan(byte[] startRow, Filter filter)
+Scan(byte[] startRow)
+

# ResultScanner

以行为单位进行返回

Result next() throws IOException
+Result[] next(int nbRows) throws IOException
+void close()
+

# 缓存与批量处理

每一个 next()调用都会为每行数据生成一个单独的 RPC 请求

可以设置扫描器缓存

void setScannerCaching(itn scannerCaching)
+int getScannerCaching()
+

缓存是面向行一级操作，批量是面向列一级操作

void setBatch(int batch)
+int getBatch
+

RPC 请求的次数=(行数*每行列数)/Min(每行的列数，批量大小)/扫描器缓存

# 各种特性

Bytes 类提供了一系列将原生 Java 类型和字节数组互转的方法。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#大数据#HBase
上次更新: 2023/06/29, 22:27:04
HBase 架构
HBase Java API 高级特性之过滤器

+ ← + HBase Java API 高级特性之过滤器→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/ad08f5/index.html b/pages/ad08f5/index.html new file mode 100644 index 00000000..d61d9f3a --- /dev/null +++ b/pages/ad08f5/index.html @@ -0,0 +1,62 @@ + + + + + + MongoDB 分片 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-20
目录

MongoDB 分片

# MongoDB 分片

# 分片集群简介

当 MongoDB 需要存储海量数据时，单节点不足以存储全量数据，且可能无法提供令人满意的吞吐量。所以，可以通过 MongoDB 分片机制来支持水平扩展。

# 分片集群特点

对应用完全透明

数据自动均衡

动态扩容

提供三种分片方式

# 分片集群组件

MongoDB 分片集群含以下组件：

img

# 分片集群的分布

MongoDB 复制集以 collection 为单位，将数据分布在集群中的各个分片上。最多允许 1024 个分片。

MongoDB 复制集的分片之间数据不重复，只有当所有分片都正常时，才能完整工作。

MongoDB 数据库可以同时包含分片和未分片的集合的 collection。分片 collection 会分布在集群中各节点上。而未分片的 collection 存储在主节点上。每个数据库都有其自己的主节点。

分片和未分片的 collection：

img

# 路由节点 mongos

要连接 MongoDB 分片集群 (opens new window)，必须连接到 mongos (opens new window) 路由器。这包括分片和未分片的 collection。客户端不应该连接到单个分片节点进行读写操作。

连接 mongos (opens new window) 的方式和连接 mongod (opens new window) 相同，例如通过 mongo (opens new window) shell 或 MongoDB 驱动程序 (opens new window)。

img

路由节点的作用：

  • 提供集群的单一入口
  • 转发应用端请求
  • 选择合适数据节点进行读写
  • 合并多个数据节点的返回

一般，路由节点 mongos 建议至少 2 个。

# 分片 Key

MongoDB 使用分片 Key 在各个分片之间分发 collection 的 document。分片 Key 由 document 中的一个或多个字段组成。

  • 从 MongoDB 4.4 开始，分片 collection 中的 document 可能缺少分片 Key 字段。在跨分片分布文档时，缺少分片 Key 字段将被视为具有空值，但在路由查询时则不会。

  • 在 MongoDB 4.2 及更早版本中，分片 Key 字段必须在每个 document 中存在一个分片 collection。

在分片 collection 时选择分片 Key。

  • 从 MongoDB 4.4 开始，您可以通过在现有 Key 中添加一个或多个后缀字段来优化 collection 的分片 Key。
  • 在 MongoDB 4.2 和更低版本中，无法在分片后更改分片 Key 的选择。

document 的分片键值决定了其在各个分片中的分布

  • 从 MongoDB 4.2 开始，除非您的分片 Key 字段是不可变的_id 字段，否则您可以更新 document 的分片键值。
  • 在 MongoDB 4.0 及更低版本中，文档的分片 Key 字段值是不可变的。

分片 Key 索引：要对已填充的 collection 进行分片，该 collection 必须具有以分片 Key 开头的索引。分片一个空 collection 时，如果该 collection 还没有针对指定分片 Key 的适当索引，则 MongoDB 会创建支持索引。

分片 Key 策略：分片 Key 的选择会影响分片集群的性能，效率和可伸缩性。分片 Key 及其后备索引的选择也会影响集群可以使用的分片策略。

MongoDB 分区将数据分片。每个分块都有基于分片 Key 的上下限。

为了在整个集群中的所有分片上实现块的均匀分布，均衡器在后台运行，并在各分片上迁移块。

# 分片策略

MongoDB 支持两种分片策略：Hash 分片和范围分片。

# Hash 分片

Hash 分片策略会先计算分片 Key 字段值的哈希值；然后，根据分片键值为每个 chunk (opens new window) 分配一个范围。

注意：使用哈希索引解析查询时，MongoDB 会自动计算哈希值，应用程序不需要计算哈希。

img

尽管分片 Key 范围可能是“接近”的，但它们的哈希值不太可能在同一 chunk (opens new window) 上。基于 Hash 的数据分发有助于更均匀的数据分布，尤其是在分片 Key 单调更改的数据集中。

但是，Hash 分片意味着对分片 Key 做范围查询时不太可能针对单个分片，从而导致更多的集群范围内的广播操作。

# 范围分片

范围分片根据分片 Key 值将数据划分为多个范围。然后，根据分片 Key 值为每个 chunk (opens new window) 分配一个范围。

img

值比较近似的一系列分片 Key 更有可能驻留在同一 chunk (opens new window) 上。范围分片的效率取决于选择的分片 Key。分片 Key 考虑不周全会导致数据分布不均，这可能会削弱分片的某些优势或导致性能瓶颈。

# 分片集群中的区域

区域可以提高跨多个数据中心的分片集群的数据局部性。

在分片集群中，可以基于分片 Key 创建分片数据区域 (opens new window)。可以将每个区域与集群中的一个或多个分片关联。分片可以与任意数量的区域关联。在平衡的集群中，MongoDB 仅将区域覆盖的 chunk (opens new window) 迁移到与该区域关联的分片。

每个区域覆盖一个或多个分片 Key 值范围。区域覆盖的每个范围始终包括其上下边界。

img

在定义要覆盖的区域的新范围时，必须使用分片 Key 中包含的字段。如果使用复合分片 Key，则范围必须包含分片 Key 的前缀。

选择分片 Key 时，应考虑将来可能使用的区域。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#文档数据库#MongoDB#分片
上次更新: 2023/06/29, 22:27:04
MongoDB 复制
MongoDB 运维

+ ← + MongoDB 运维→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/addb05/index.html b/pages/addb05/index.html new file mode 100644 index 00000000..6534c883 --- /dev/null +++ b/pages/addb05/index.html @@ -0,0 +1,59 @@ + + + + + + 数据库中间件和代理 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-04-11
目录

数据库中间件和代理

# 数据库中间件和代理

# 📖 内容

# 📚 资料

# 🚪 传送

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#中间件
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/b1a116/index.html b/pages/b1a116/index.html new file mode 100644 index 00000000..ce330456 --- /dev/null +++ b/pages/b1a116/index.html @@ -0,0 +1,59 @@ + + + + + + MongoDB 教程 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-09
目录

MongoDB 教程

# MongoDB 教程

MongoDB 是一个基于文档的分布式数据库，由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。

MongoDB 是一个介于关系型数据库和非关系型数据库之间的产品。它是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似 json 的 bson 格式，因此可以存储比较复杂的数据类型。

MongoDB 最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

# 📖 内容

# MongoDB 应用指南

# MongoDB 的 CRUD 操作

# MongoDB 聚合操作

# MongoDB 事务

# MongoDB 建模

# MongoDB 建模示例

# MongoDB 索引

# MongoDB 复制

# MongoDB 分片

# MongoDB 运维

# 📚 资料

# 🚪 传送

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#文档数据库#MongoDB
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/b59ba2/index.html b/pages/b59ba2/index.html new file mode 100644 index 00000000..6f015c53 --- /dev/null +++ b/pages/b59ba2/index.html @@ -0,0 +1,104 @@ + + + + + + HBase Java API 管理功能 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2023-04-13
目录

HBase Java API 管理功能

# HBase Java API 管理功能

# 初始化 Admin 实例

Configuration conf = HBaseConfiguration.create();
+Connection connection = ConnectionFactory.createConnection(conf);
+Admin admin = connection.getAdmin();
+

# 管理命名空间

# 查看命名空间

TableName[] tableNames = admin.listTableNamesByNamespace("test");
+for (TableName tableName : tableNames) {
+    System.out.println(tableName.getName());
+}
+

# 创建命名空间

NamespaceDescriptor namespace = NamespaceDescriptor.create("test").build();
+admin.createNamespace(namespace);
+

# 修改命名空间

NamespaceDescriptor namespace = NamespaceDescriptor.create("test")
+                                                   .addConfiguration("Description", "Test Namespace")
+                                                   .build();
+admin.modifyNamespace(namespace);
+

# 删除命名空间

admin.deleteNamespace("test");
+

# 管理表

# 创建表

TableName tableName = TableName.valueOf("test:test");
+HTableDescriptor tableDescriptor = new HTableDescriptor(tableName);
+HColumnDescriptor columnDescriptor = new HColumnDescriptor(Bytes.toBytes("cf"));
+tableDescriptor.addFamily(columnDescriptor);
+admin.createTable(tableDescriptor);
+

# 删除表

admin.deleteTable(TableName.valueOf("test:test"));
+

# 修改表

// 原始表
+TableName tableName = TableName.valueOf("test:test");
+HColumnDescriptor columnDescriptor = new HColumnDescriptor("cf1");
+HTableDescriptor tableDescriptor = new HTableDescriptor(tableName)
+    .addFamily(columnDescriptor)
+    .setValue("Description", "Original Table");
+admin.createTable(tableDescriptor, Bytes.toBytes(1L), Bytes.toBytes(10000L), 50);
+
+// 修改表
+HTableDescriptor newTableDescriptor = admin.getTableDescriptor(tableName);
+HColumnDescriptor newColumnDescriptor = new HColumnDescriptor("cf2");
+newTableDescriptor.addFamily(newColumnDescriptor)
+                  .setMaxFileSize(1024 * 1024 * 1024L)
+                  .setValue("Description", "Modified Table");
+
+// 修改表必须先禁用再想修改
+admin.disableTable(tableName);
+admin.modifyTable(tableName, newTableDescriptor);
+

# 禁用表

需要注意：HBase 表在删除前，必须先禁用。

admin.disableTable(TableName.valueOf("test:test"));
+

# 启用表

admin.enableTable(TableName.valueOf("test:test"));
+

# 查看表是否有效

boolean isOk = admin.isTableAvailable(tableName);
+System.out.println("Table available: " + isOk);
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#大数据#HBase#API
上次更新: 2023/06/29, 22:27:04
HBase Java API 其他高级特性
HBase 运维

+ ← + HBase 运维→ +

最近更新
01
+ HBase Java API 其他高级特性 +
03-31
02
+ HBase 数据模型 +
03-16
03
+ HBase Java API 高级特性之协处理器 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/b71c9e/index.html b/pages/b71c9e/index.html new file mode 100644 index 00000000..fbbec33b --- /dev/null +++ b/pages/b71c9e/index.html @@ -0,0 +1,178 @@ + + + + + + SQL 语法基础特性 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2018-06-15
目录

SQL 语法基础特性

# SQL 语法基础特性

本文针对关系型数据库的基本语法。限于篇幅，本文侧重说明用法，不会展开讲解特性、原理。

本文语法主要针对 Mysql，但大部分的语法对其他关系型数据库也适用。

img

# SQL 简介

# 数据库术语

  • 数据库（database） - 保存有组织的数据的容器（通常是一个文件或一组文件）。
  • 数据表（table） - 某种特定类型数据的结构化清单。
  • 模式（schema） - 关于数据库和表的布局及特性的信息。模式定义了数据在表中如何存储，包含存储什么样的数据，数据如何分解，各部分信息如何命名等信息。数据库和表都有模式。
  • 列（column） - 表中的一个字段。所有表都是由一个或多个列组成的。
  • 行（row） - 表中的一个记录。
  • 主键（primary key） - 一列（或一组列），其值能够唯一标识表中每一行。

# SQL 语法

SQL（Structured Query Language)，标准 SQL 由 ANSI 标准委员会管理，从而称为 ANSI SQL。各个 DBMS 都有自己的实现，如 PL/SQL、Transact-SQL 等。

# SQL 语法结构

img

SQL 语法结构包括：

  • 子句 - 是语句和查询的组成成分。（在某些情况下，这些都是可选的。）
  • 表达式 - 可以产生任何标量值，或由列和行的数据库表
  • 谓词 - 给需要评估的 SQL 三值逻辑（3VL）（true/false/unknown）或布尔真值指定条件，并限制语句和查询的效果，或改变程序流程。
  • 查询 - 基于特定条件检索数据。这是 SQL 的一个重要组成部分。
  • 语句 - 可以持久地影响纲要和数据，也可以控制数据库事务、程序流程、连接、会话或诊断。

# SQL 语法要点

  • SQL 语句不区分大小写，但是数据库表名、列名和值是否区分，依赖于具体的 DBMS 以及配置。

例如：SELECT 与 select 、Select 是相同的。

  • 多条 SQL 语句必须以分号（;）分隔。

  • 处理 SQL 语句时，所有空格都被忽略。SQL 语句可以写成一行，也可以分写为多行。

-- 一行 SQL 语句
+UPDATE user SET username='robot', password='robot' WHERE username = 'root';
+
+-- 多行 SQL 语句
+UPDATE user
+SET username='robot', password='robot'
+WHERE username = 'root';
+
  • SQL 支持三种注释
## 注释1
+-- 注释2
+/* 注释3 */
+

# SQL 分类

# 数据定义语言（DDL）

数据定义语言（Data Definition Language，DDL）是 SQL 语言集中负责数据结构定义与数据库对象定义的语言。

DDL 的主要功能是定义数据库对象。

DDL 的核心指令是 CREATE、ALTER、DROP。

# 数据操纵语言（DML）

数据操纵语言（Data Manipulation Language, DML）是用于数据库操作，对数据库其中的对象和数据运行访问工作的编程语句。

DML 的主要功能是 访问数据，因此其语法都是以读写数据库为主。

DML 的核心指令是 INSERT、UPDATE、DELETE、SELECT。这四个指令合称 CRUD(Create, Read, Update, Delete)，即增删改查。

# 事务控制语言（TCL）

事务控制语言 (Transaction Control Language, TCL) 用于管理数据库中的事务。这些用于管理由 DML 语句所做的更改。它还允许将语句分组为逻辑事务。

TCL 的核心指令是 COMMIT、ROLLBACK。

# 数据控制语言（DCL）

数据控制语言 (Data Control Language, DCL) 是一种可对数据访问权进行控制的指令，它可以控制特定用户账户对数据表、查看表、预存程序、用户自定义函数等数据库对象的控制权。

DCL 的核心指令是 GRANT、REVOKE。

DCL 以控制用户的访问权限为主，因此其指令作法并不复杂，可利用 DCL 控制的权限有：CONNECT、SELECT、INSERT、UPDATE、DELETE、EXECUTE、USAGE、REFERENCES。

根据不同的 DBMS 以及不同的安全性实体，其支持的权限控制也有所不同。

（以下为 DML 语句用法）

# 增删改查（CRUD）

增删改查，又称为 CRUD，是数据库基本操作中的基本操作。

# 插入数据

  • INSERT INTO 语句用于向表中插入新记录。

# 插入完整的行

INSERT INTO user
+VALUES (10, 'root', 'root', 'xxxx@163.com');
+

# 插入行的一部分

INSERT INTO user(username, password, email)
+VALUES ('admin', 'admin', 'xxxx@163.com');
+

# 插入查询出来的数据

INSERT INTO user(username)
+SELECT name
+FROM account;
+

# 更新数据

  • UPDATE 语句用于更新表中的记录。
UPDATE user
+SET username='robot', password='robot'
+WHERE username = 'root';
+

# 删除数据

  • DELETE 语句用于删除表中的记录。
  • TRUNCATE TABLE 可以清空表，也就是删除所有行。

# 删除表中的指定数据

DELETE FROM user WHERE username = 'robot';
+

# 清空表中的数据

TRUNCATE TABLE user;
+

# 查询数据

  • SELECT 语句用于从数据库中查询数据。
  • DISTINCT 用于返回唯一不同的值。它作用于所有列，也就是说所有列的值都相同才算相同。
  • LIMIT 限制返回的行数。可以有两个参数，第一个参数为起始行，从 0 开始；第二个参数为返回的总行数。 +
    • ASC ：升序（默认）
    • DESC ：降序

# 查询单列

SELECT prod_name FROM products;
+

# 查询多列

SELECT prod_id, prod_name, prod_price FROM products;
+

# 查询所有列

SELECT * FROM products;
+

# 查询不同的值

SELECT DISTINCT vend_id FROM products;
+

# 限制查询数量

-- 返回前 5 行
+SELECT * FROM products LIMIT 5;
+SELECT * FROM products LIMIT 0, 5;
+-- 返回第 3 ~ 5 行
+SELECT * FROM products LIMIT 2, 3;
+

# 过滤数据（WHERE）

子查询是嵌套在较大查询中的 SQL 查询。子查询也称为内部查询或内部选择，而包含子查询的语句也称为外部查询或外部选择。

  • 子查询可以嵌套在 SELECT，INSERT，UPDATE 或 DELETE 语句内或另一个子查询中。

  • 子查询通常会在另一个 SELECT 语句的 WHERE 子句中添加。

  • 您可以使用比较运算符，如 >，<，或 =。比较运算符也可以是多行运算符，如 IN，ANY 或 ALL。

  • 子查询必须被圆括号 () 括起来。

  • 内部查询首先在其父查询之前执行，以便可以将内部查询的结果传递给外部查询。执行过程可以参考下图：

    sql-subqueries

子查询的子查询

SELECT cust_name, cust_contact
+FROM customers
+WHERE cust_id IN (SELECT cust_id
+                  FROM orders
+                  WHERE order_num IN (SELECT order_num
+                                      FROM orderitems
+                                      WHERE prod_id = 'RGAN01'));
+

# WHERE 子句

在 SQL 语句中，数据根据 WHERE 子句中指定的搜索条件进行过滤。

WHERE 子句的基本格式如下：

SELECT ……(列名) FROM ……(表名) WHERE ……(子句条件)
+

WHERE 子句用于过滤记录，即缩小访问数据的范围。WHERE 后跟一个返回 true 或 false 的条件。

WHERE 可以与 SELECT，UPDATE 和 DELETE 一起使用。

SELECT 语句中的 WHERE 子句

SELECT * FROM Customers
+WHERE cust_name = 'Kids Place';
+

UPDATE 语句中的 WHERE 子句

UPDATE Customers
+SET cust_name = 'Jack Jones'
+WHERE cust_name = 'Kids Place';
+

DELETE 语句中的 WHERE 子句

DELETE FROM Customers
+WHERE cust_name = 'Kids Place';
+

可以在 WHERE 子句中使用的操作符：

# 比较操作符

运算符 描述
= 等于
<> 不等于。注释：在 SQL 的一些版本中，该操作符可被写成 !=
> 大于
< 小于
>= 大于等于
<= 小于等于

# 范围操作符

运算符 描述
BETWEEN 在某个范围内
IN 指定针对某个列的多个可能值

  • IN 操作符在 WHERE 子句中使用，作用是在指定的几个特定值中任选一个值。

  • BETWEEN 操作符在 WHERE 子句中使用，作用是选取介于某个范围内的值。

IN 示例

SELECT *
+FROM products
+WHERE vend_id IN ('DLL01', 'BRS01');
+

BETWEEN 示例

SELECT *
+FROM products
+WHERE prod_price BETWEEN 3 AND 5;
+

# 逻辑操作符

运算符 描述
AND 并且（与）
OR 或者（或）
NOT 否定（非）

AND、OR、NOT 是用于对过滤条件的逻辑处理指令。

  • AND 优先级高于 OR，为了明确处理顺序，可以使用 ()。AND 操作符表示左右条件都要满足。

  • OR 操作符表示左右条件满足任意一个即可。

  • NOT 操作符用于否定一个条件。

AND 示例

SELECT prod_id, prod_name, prod_price
+FROM products
+WHERE vend_id = 'DLL01' AND prod_price <= 4;
+

OR 示例

SELECT prod_id, prod_name, prod_price
+FROM products
+WHERE vend_id = 'DLL01' OR vend_id = 'BRS01';
+

NOT 示例

SELECT *
+FROM products
+WHERE prod_price NOT BETWEEN 3 AND 5;
+

# 通配符

运算符 描述
LIKE 搜索某种模式
% 表示任意字符出现任意次数
_ 表示任意字符出现一次
[] 必须匹配指定位置的一个字符

LIKE 操作符在 WHERE 子句中使用，作用是确定字符串是否匹配模式。只有字段是文本值时才使用 LIKE。

LIKE 支持以下通配符匹配选项：

  • % 表示任何字符出现任意次数。
  • _ 表示任何字符出现一次。
  • [] 必须匹配指定位置的一个字符。

注意：不要滥用通配符，通配符位于开头处匹配会非常慢。

% 示例：

SELECT prod_id, prod_name, prod_price
+FROM products
+WHERE prod_name LIKE '%bean bag%';
+

_ 示例：

SELECT prod_id, prod_name, prod_price
+FROM products
+WHERE prod_name LIKE '__ inch teddy bear';
+

# 排序（ORDER BY）

ORDER BY 用于对结果集进行排序。

ORDER BY 有两种排序模式：

  • ASC ：升序（默认）
  • DESC ：降序

可以按多个列进行排序，并且为每个列指定不同的排序方式。

指定多个列的排序示例：

SELECT * FROM products
+ORDER BY prod_price DESC, prod_name ASC;
+

# 数据定义（CREATE、ALTER、DROP）

DDL 的主要功能是定义数据库对象（如：数据库、数据表、视图、索引等）。

# 数据库（DATABASE）

# 创建数据库

CREATE DATABASE IF NOT EXISTS db_tutorial;
+

# 删除数据库

DROP DATABASE IF EXISTS db_tutorial;
+

# 选择数据库

USE db_tutorial;
+

# 数据表（TABLE）

# 删除数据表

DROP TABLE IF EXISTS user;
+DROP TABLE IF EXISTS vip_user;
+

# 创建数据表

普通创建

CREATE TABLE user (
+    id       INT(10) UNSIGNED NOT NULL COMMENT 'Id',
+    username VARCHAR(64)      NOT NULL DEFAULT 'default' COMMENT '用户名',
+    password VARCHAR(64)      NOT NULL DEFAULT 'default' COMMENT '密码',
+    email    VARCHAR(64)      NOT NULL DEFAULT 'default' COMMENT '邮箱'
+) COMMENT ='用户表';
+

根据已有的表创建新表

CREATE TABLE vip_user AS
+SELECT *
+FROM user;
+

# 修改数据表

# 添加列
ALTER TABLE user
+ADD age int(3);
+
# 删除列
ALTER TABLE user
+DROP COLUMN age;
+
# 修改列
ALTER TABLE `user`
+MODIFY COLUMN age tinyint;
+

# 视图（VIEW）

视图是基于 SQL 语句的结果集的可视化的表。视图是虚拟的表，本身不存储数据，也就不能对其进行索引操作。对视图的操作和对普通表的操作一样。

视图的作用：

  • 简化复杂的 SQL 操作，比如复杂的连接。
  • 只使用实际表的一部分数据。
  • 通过只给用户访问视图的权限，保证数据的安全性。
  • 更改数据格式和表示。

# 创建视图

CREATE VIEW top_10_user_view AS
+SELECT id, username
+FROM user
+WHERE id < 10;
+

# 删除视图

DROP VIEW top_10_user_view;
+

# 索引（INDEX）

通过索引可以更加快速高效地查询数据。用户无法看到索引，它们只能被用来加速查询。

更新一个包含索引的表需要比更新一个没有索引的表花费更多的时间，这是由于索引本身也需要更新。因此，理想的做法是仅仅在常常被搜索的列（以及表）上面创建索引。

唯一索引：唯一索引表明此索引的每一个索引值只对应唯一的数据记录。

# 创建索引

CREATE INDEX idx_email
+    ON user(email);
+

# 创建唯一索引

CREATE UNIQUE INDEX uniq_username
+    ON user(username);
+

# 删除索引

ALTER TABLE user
+DROP INDEX idx_email;
+ALTER TABLE user
+DROP INDEX uniq_username;
+

# 添加主键

ALTER TABLE user
+ADD PRIMARY KEY (id);
+

# 删除主键

ALTER TABLE user
+DROP PRIMARY KEY;
+

# 约束

SQL 约束用于规定表中的数据规则。

  • 如果存在违反约束的数据行为，行为会被约束终止。
  • 约束可以在创建表时规定（通过 CREATE TABLE 语句），或者在表创建之后规定（通过 ALTER TABLE 语句）。
  • 约束类型 +
    • NOT NULL - 指示某列不能存储 NULL 值。
    • UNIQUE - 保证某列的每行必须有唯一的值。
    • PRIMARY KEY - NOT NULL 和 UNIQUE 的结合。确保某列（或两个列多个列的结合）有唯一标识，有助于更容易更快速地找到表中的一个特定的记录。
    • FOREIGN KEY - 保证一个表中的数据匹配另一个表中的值的参照完整性。
    • CHECK - 保证列中的值符合指定的条件。
    • DEFAULT - 规定没有给列赋值时的默认值。

创建表时使用约束条件：

CREATE TABLE Users (
+  Id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增Id',
+  Username VARCHAR(64) NOT NULL UNIQUE DEFAULT 'default' COMMENT '用户名',
+  Password VARCHAR(64) NOT NULL DEFAULT 'default' COMMENT '密码',
+  Email VARCHAR(64) NOT NULL DEFAULT 'default' COMMENT '邮箱地址',
+  Enabled TINYINT(4) DEFAULT NULL COMMENT '是否有效',
+  PRIMARY KEY (Id)
+) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COMMENT='用户表';
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#SQL
上次更新: 2023/06/29, 22:27:04
关系型数据库面试
扩展 SQL

+ ← + 扩展 SQL→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/b7f079/index.html b/pages/b7f079/index.html new file mode 100644 index 00000000..813d032d --- /dev/null +++ b/pages/b7f079/index.html @@ -0,0 +1,122 @@ + + + + + + Elastic 技术栈之 Filebeat | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-16
目录

Elastic 技术栈之 Filebeat

# Elastic 技术栈之 Filebeat

# 简介

Beats 是安装在服务器上的数据中转代理。

Beats 可以将数据直接传输到 Elasticsearch 或传输到 Logstash 。

img

Beats 有多种类型，可以根据实际应用需要选择合适的类型。

常用的类型有：

  • **Packetbeat：**网络数据包分析器，提供有关您的应用程序服务器之间交换的事务的信息。
  • **Filebeat：**从您的服务器发送日志文件。
  • **Metricbeat：**是一个服务器监视代理程序，它定期从服务器上运行的操作系统和服务收集指标。
  • **Winlogbeat：**提供 Windows 事件日志。

参考

更多 Beats 类型可以参考：community-beats (opens new window)

说明

由于本人工作中只应用了 FileBeat，所以后面内容仅介绍 FileBeat 。

# FileBeat 的作用

相比 Logstash，FileBeat 更加轻量化。

在任何环境下，应用程序都有停机的可能性。 Filebeat 读取并转发日志行，如果中断，则会记住所有事件恢复联机状态时所在位置。

Filebeat 带有内部模块（auditd，Apache，Nginx，System 和 MySQL），可通过一个指定命令来简化通用日志格式的收集，解析和可视化。

FileBeat 不会让你的管道超负荷。FileBeat 如果是向 Logstash 传输数据，当 Logstash 忙于处理数据，会通知 FileBeat 放慢读取速度。一旦拥塞得到解决，FileBeat 将恢复到原来的速度并继续传播。

img

# 安装

Unix / Linux 系统建议使用下面方式安装，因为比较通用。

wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.1.1-linux-x86_64.tar.gz
+tar -zxf filebeat-6.1.1-linux-x86_64.tar.gz
+

参考

更多内容可以参考：filebeat-installation (opens new window)

# 配置

# 配置文件

首先，需要知道的是：filebeat.yml 是 filebeat 的配置文件。配置文件的路径会因为你安装方式的不同而变化。

Beat 所有系列产品的配置文件都基于 YAML (opens new window) 格式，FileBeat 当然也不例外。

filebeat.yml 部分配置示例：

filebeat:
+  prospectors:
+    - type: log
+      paths:
+        - /var/log/*.log
+      multiline:
+        pattern: '^['
+        match: after
+

参考

更多 filebeat 配置内容可以参考：配置 filebeat (opens new window)

更多 filebeat.yml 文件格式内容可以参考：filebeat.yml 文件格式 (opens new window)

# 重要配置项

# filebeat.prospectors

（文件监视器）用于指定需要关注的文件。

示例

filebeat.prospectors:
+  - type: log
+    enabled: true
+    paths:
+      - /var/log/*.log
+

# output.elasticsearch

如果你希望使用 filebeat 直接向 elasticsearch 输出数据，需要配置 output.elasticsearch 。

示例

output.elasticsearch:
+  hosts: ['192.168.1.42:9200']
+

# output.logstash

如果你希望使用 filebeat 向 logstash 输出数据，然后由 logstash 再向 elasticsearch 输出数据，需要配置 output.logstash。

注意

相比于向 elasticsearch 输出数据，个人更推荐向 logstash 输出数据。

因为 logstash 和 filebeat 一起工作时，如果 logstash 忙于处理数据，会通知 FileBeat 放慢读取速度。一旦拥塞得到解决，FileBeat 将恢复到原来的速度并继续传播。这样，可以减少管道超负荷的情况。

示例

output.logstash:
+  hosts: ['127.0.0.1:5044']
+

此外，还需要在 logstash 的配置文件（如 logstash.conf）中指定 beats input 插件：

input {
+  beats {
+    port => 5044 # 此端口需要与 filebeat.yml 中的端口相同
+  }
+}
+
+# The filter part of this file is commented out to indicate that it is
+# optional.
+# filter {
+#
+# }
+
+output {
+  elasticsearch {
+    hosts => "localhost:9200"
+    manage_template => false
+    index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}"
+    document_type => "%{[@metadata][type]}"
+  }
+}
+

# setup.kibana

如果打算使用 Filebeat 提供的 Kibana 仪表板，需要配置 setup.kibana 。

示例

setup.kibana:
+  host: 'localhost:5601'
+

# setup.template.settings

在 Elasticsearch 中，索引模板 (opens new window)用于定义设置和映射，以确定如何分析字段。

在 Filebeat 中，setup.template.settings 用于配置索引模板。

Filebeat 推荐的索引模板文件由 Filebeat 软件包安装。如果您接受 filebeat.yml 配置文件中的默认配置，Filebeat 在成功连接到 Elasticsearch 后自动加载模板。

您可以通过在 Filebeat 配置文件中配置模板加载选项来禁用自动模板加载，或加载自己的模板。您还可以设置选项来更改索引和索引模板的名称。

参考

更多内容可以参考：filebeat-template (opens new window)

说明

如无必要，使用 Filebeat 配置文件中的默认索引模板即可。

# setup.dashboards

Filebeat 附带了示例 Kibana 仪表板。在使用仪表板之前，您需要创建索引模式 filebeat- *，并将仪表板加载到 Kibana 中。为此，您可以运行 setup 命令或在 filebeat.yml 配置文件中配置仪表板加载。

为了在 Kibana 中加载 Filebeat 的仪表盘，需要在 filebeat.yml 配置中启动开关：

setup.dashboards.enabled: true
+

参考

更多内容可以参考：configuration-dashboards (opens new window)

# 命令

filebeat 提供了一系列命令来完成各种功能。

执行命令方式：

./filebeat COMMAND
+

参考

更多内容可以参考：command-line-options (opens new window)

说明

个人认为命令行没有必要一一掌握，因为绝大部分功能都可以通过配置来完成。且通过命令行指定功能这种方式要求每次输入同样参数，不利于固化启动方式。

最重要的当然是启动命令 run 了。

示例 指定配置文件启动

./filebeat run -e -c filebeat.yml -d "publish"
+./filebeat -e -c filebeat.yml -d "publish" # run 可以省略
+

# 模块

Filebeat 提供了一套预构建的模块，让您可以快速实施和部署日志监视解决方案，并附带示例仪表板和数据可视化。这些模块支持常见的日志格式，例如 Nginx，Apache2 和 MySQL 等。

# 运行模块的步骤

  • 配置 elasticsearch 和 kibana
output.elasticsearch:
+  hosts: ["myEShost:9200"]
+  username: "elastic"
+  password: "elastic"
+setup.kibana:
+  host: "mykibanahost:5601"
+  username: "elastic"
+  password: "elastic
+

username 和 password 是可选的，如果不需要认证则不填。

  • 初始化环境

执行下面命令，filebeat 会加载推荐索引模板。

./filebeat setup -e
+
  • 指定模块

执行下面命令，指定希望加载的模块。

./filebeat -e --modules system,nginx,mysql
+

参考

更多内容可以参考： 配置 filebeat 模块 (opens new window) | filebeat 支持模块 (opens new window)

# 原理

Filebeat 有两个主要组件：

harvester：负责读取一个文件的内容。它会逐行读取文件内容，并将内容发送到输出目的地。

prospector：负责管理 harvester 并找到所有需要读取的文件源。比如类型是日志，prospector 就会遍历制定路径下的所有匹配要求的文件。

filebeat.prospectors:
+  - type: log
+    paths:
+      - /var/log/*.log
+      - /var/path2/*.log
+

Filebeat 保持每个文件的状态，并经常刷新注册表文件中的磁盘状态。状态用于记住 harvester 正在读取的最后偏移量，并确保发送所有日志行。

Filebeat 将每个事件的传递状态存储在注册表文件中。所以它能保证事件至少传递一次到配置的输出，没有数据丢失。

# 资料

Beats 官方文档 (opens new window)

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elastic#Filebeat
上次更新: 2023/06/29, 22:27:04
Elastic 快速入门
Filebeat 运维

+ ← + Filebeat 运维→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/bb43eb/index.html b/pages/bb43eb/index.html new file mode 100644 index 00000000..42cafe60 --- /dev/null +++ b/pages/bb43eb/index.html @@ -0,0 +1,59 @@ + + + + + + 关系型数据库 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-04-11
目录

关系型数据库

# 关系型数据库

# 📖 内容

# 关系型数据库综合

# Mysql

img

# 其他

# 📚 资料

# 综合

# Mysql

# 其他

# 🚪 传送

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/bdcd7e/index.html b/pages/bdcd7e/index.html new file mode 100644 index 00000000..e958f343 --- /dev/null +++ b/pages/bdcd7e/index.html @@ -0,0 +1,165 @@ + + + + + + sqlite | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2019-08-22
目录

sqlite

# SQLite

SQLite 是一个无服务器的、零配置的、事务性的的开源数据库引擎。 +💻 完整示例源码 (opens new window)

# SQLite 简介

SQLite 是一个C语言编写的轻量级、全功能、无服务器、零配置的的开源数据库引擎。

SQLite 的设计目标是嵌入式的数据库，很多嵌入式产品中都使用了它。SQLite 十分轻量，占用资源非常的低，在嵌入式设备中，可能只需要几百K的内存就够了。SQLite 能够支持Windows/Linux/Unix等等主流的操作系统，同时能够跟很多程序语言相结合，同样比起Mysql、PostgreSQL这两款开源的世界著名数据库管理系统来讲，它的处理速度比他们都快。

SQLite 大小只有 3M 左右，可以将整个 SQLite 嵌入到应用中，而不用采用传统的客户端／服务器（Client/Server）的架构。这样做的好处就是非常轻便，在许多智能设备和应用中都可以使用 SQLite，比如微信就采用了 SQLite 作为本地聊天记录的存储。

# 优点

  • SQLite 是自给自足的，这意味着不需要任何外部的依赖。
  • SQLite 是无服务器的、零配置的，这意味着不需要安装或管理。
  • SQLite 事务是完全兼容 ACID 的，允许从多个进程或线程安全访问。
  • SQLite 是非常小的，是轻量级的，完全配置时小于 400KiB，省略可选功能配置时小于 250KiB。
  • SQLite 支持 SQL92（SQL2）标准的大多数查询语言的功能。
  • 一个完整的 SQLite 数据库是存储在一个单一的跨平台的磁盘文件。
  • SQLite 使用 ANSI-C 编写的，并提供了简单和易于使用的 API。
  • SQLite 可在 UNIX（Linux, Mac OS-X, Android, iOS）和 Windows（Win32, WinCE, WinRT）中运行。

# 局限

特性 描述
RIGHT OUTER JOIN 只实现了 LEFT OUTER JOIN。
FULL OUTER JOIN 只实现了 LEFT OUTER JOIN。
ALTER TABLE 支持 RENAME TABLE 和 ALTER TABLE 的 ADD COLUMN variants 命令，不支持 DROP COLUMN、ALTER COLUMN、ADD CONSTRAINT。
Trigger 支持 支持 FOR EACH ROW 触发器，但不支持 FOR EACH STATEMENT 触发器。
VIEWs 在 SQLite 中，视图是只读的。您不可以在视图上执行 DELETE、INSERT 或 UPDATE 语句。
GRANT 和 REVOKE 可以应用的唯一的访问权限是底层操作系统的正常文件访问权限。

# 安装

Sqlite 可在 UNIX（Linux, Mac OS-X, Android, iOS）和 Windows（Win32, WinCE, WinRT）中运行。

一般，Linux 和 Mac 上会预安装 sqlite。如果没有安装，可以在官方下载地址 (opens new window)下载合适安装版本，自行安装。

# SQLite 语法

这里不会详细列举所有 SQL 语法，仅列举 SQLite 除标准 SQL 以外的，一些自身特殊的 SQL 语法。

📖 扩展阅读：标准 SQL 基本语法 (opens new window)

# 大小写敏感

SQLite 是不区分大小写的，但也有一些命令是大小写敏感的，比如 GLOB 和 glob 在 SQLite 的语句中有不同的含义。

# 注释

-- 单行注释
+/*
+ 多行注释1
+ 多行注释2
+ */
+

# 创建数据库

如下，创建一个名为 test 的数据库：

$ sqlite3 test.db
+SQLite version 3.7.17 2013-05-20 00:56:22
+Enter ".help" for instructions
+Enter SQL statements terminated with a ";"
+

# 查看数据库

sqlite> .databases
+seq  name             file
+---  ---------------  ----------------------------------------------------------
+0    main             /root/test.db
+

# 退出数据库

sqlite> .quit
+

# 附加数据库

假设这样一种情况，当在同一时间有多个数据库可用，您想使用其中的任何一个。

SQLite 的 ATTACH DATABASE 语句是用来选择一个特定的数据库，使用该命令后，所有的 SQLite 语句将在附加的数据库下执行。

sqlite> ATTACH DATABASE 'test.db' AS 'test';
+sqlite> .databases
+seq  name             file
+---  ---------------  ----------------------------------------------------------
+0    main             /root/test.db
+2    test             /root/test.db
+

🔔 注意：数据库名 main 和 temp 被保留用于主数据库和存储临时表及其他临时数据对象的数据库。这两个数据库名称可用于每个数据库连接，且不应该被用于附加，否则将得到一个警告消息。

# 分离数据库

SQLite 的 DETACH DATABASE 语句是用来把命名数据库从一个数据库连接分离和游离出来，连接是之前使用 ATTACH 语句附加的。

sqlite> .databases
+seq  name             file
+---  ---------------  ----------------------------------------------------------
+0    main             /root/test.db
+2    test             /root/test.db
+sqlite> DETACH DATABASE 'test';
+sqlite> .databases
+seq  name             file
+---  ---------------  ----------------------------------------------------------
+0    main             /root/test.db
+

# 备份数据库

如下，备份 test 数据库到 /home/test.sql

sqlite3 test.db .dump > /home/test.sql
+

# 恢复数据库

如下，根据 /home/test.sql 恢复 test 数据库

sqlite3 test.db < test.sql
+

# SQLite 数据类型

SQLite 使用一个更普遍的动态类型系统。在 SQLite 中，值的数据类型与值本身是相关的，而不是与它的容器相关。

# SQLite 存储类

每个存储在 SQLite 数据库中的值都具有以下存储类之一：

存储类 描述
NULL 值是一个 NULL 值。
INTEGER 值是一个带符号的整数，根据值的大小存储在 1、2、3、4、6 或 8 字节中。
REAL 值是一个浮点值，存储为 8 字节的 IEEE 浮点数字。
TEXT 值是一个文本字符串，使用数据库编码（UTF-8、UTF-16BE 或 UTF-16LE）存储。
BLOB 值是一个 blob 数据，完全根据它的输入存储。

SQLite 的存储类稍微比数据类型更普遍。INTEGER 存储类，例如，包含 6 种不同的不同长度的整数数据类型。

# SQLite 亲和(Affinity)类型

SQLite 支持列的亲和类型概念。任何列仍然可以存储任何类型的数据，当数据插入时，该字段的数据将会优先采用亲缘类型作为该值的存储方式。SQLite 目前的版本支持以下五种亲缘类型：

亲和类型 描述
TEXT 数值型数据在被插入之前，需要先被转换为文本格式，之后再插入到目标字段中。
NUMERIC 当文本数据被插入到亲缘性为 NUMERIC 的字段中时，如果转换操作不会导致数据信息丢失以及完全可逆，那么 SQLite 就会将该文本数据转换为 INTEGER 或 REAL 类型的数据，如果转换失败，SQLite 仍会以 TEXT 方式存储该数据。对于 NULL 或 BLOB 类型的新数据，SQLite 将不做任何转换，直接以 NULL 或 BLOB 的方式存储该数据。需要额外说明的是，对于浮点格式的常量文本，如"30000.0"，如果该值可以转换为 INTEGER 同时又不会丢失数值信息，那么 SQLite 就会将其转换为 INTEGER 的存储方式。
INTEGER 对于亲缘类型为 INTEGER 的字段，其规则等同于 NUMERIC，唯一差别是在执行 CAST 表达式时。
REAL 其规则基本等同于 NUMERIC，唯一的差别是不会将"30000.0"这样的文本数据转换为 INTEGER 存储方式。
NONE 不做任何的转换，直接以该数据所属的数据类型进行存储。

# SQLite 亲和类型(Affinity)及类型名称

下表列出了当创建 SQLite3 表时可使用的各种数据类型名称，同时也显示了相应的亲和类型：

数据类型 亲和类型
INT, INTEGER, TINYINT, SMALLINT, MEDIUMINT, BIGINT, UNSIGNED BIG INT, INT2, INT8 INTEGER
CHARACTER(20), VARCHAR(255), VARYING CHARACTER(255), NCHAR(55), NATIVE CHARACTER(70), NVARCHAR(100), TEXT, CLOB TEXT
BLOB, no datatype specified NONE
REAL, DOUBLE, DOUBLE PRECISION, FLOAT REAL
NUMERIC, DECIMAL(10,5), BOOLEAN, DATE, DATETIME NUMERIC

# Boolean 数据类型

SQLite 没有单独的 Boolean 存储类。相反，布尔值被存储为整数 0（false）和 1（true）。

# Date 与 Time 数据类型

SQLite 没有一个单独的用于存储日期和/或时间的存储类，但 SQLite 能够把日期和时间存储为 TEXT、REAL 或 INTEGER 值。

存储类 日期格式
TEXT 格式为 "YYYY-MM-DD HH:MM:SS.SSS" 的日期。
REAL 从公元前 4714 年 11 月 24 日格林尼治时间的正午开始算起的天数。
INTEGER 从 1970-01-01 00:00:00 UTC 算起的秒数。

您可以以任何上述格式来存储日期和时间，并且可以使用内置的日期和时间函数来自由转换不同格式。

# SQLite 命令

# 快速开始

# 进入 SQLite 控制台

$ sqlite3
+SQLite version 3.7.17 2013-05-20 00:56:22
+Enter ".help" for instructions
+Enter SQL statements terminated with a ";"
+sqlite>
+

# 进入 SQLite 控制台并指定数据库

$ sqlite3 test.db
+SQLite version 3.7.17 2013-05-20 00:56:22
+Enter ".help" for instructions
+Enter SQL statements terminated with a ";"
+sqlite>
+

# 退出 SQLite 控制台

sqlite>.quit
+

# 查看命令帮助

sqlite>.help
+

# 常用命令清单

命令 描述
.backup ?DB? FILE 备份 DB 数据库（默认是 "main"）到 FILE 文件。
.bail ON|OFF 发生错误后停止。默认为 OFF。
.databases 列出数据库的名称及其所依附的文件。
.dump ?TABLE? 以 SQL 文本格式转储数据库。如果指定了 TABLE 表，则只转储匹配 LIKE 模式的 TABLE 表。
.echo ON|OFF 开启或关闭 echo 命令。
.exit 退出 SQLite 提示符。
.explain ON|OFF 开启或关闭适合于 EXPLAIN 的输出模式。如果没有带参数，则为 EXPLAIN on，及开启 EXPLAIN。
.header(s) ON|OFF 开启或关闭头部显示。
.help 显示消息。
.import FILE TABLE 导入来自 FILE 文件的数据到 TABLE 表中。
.indices ?TABLE? 显示所有索引的名称。如果指定了 TABLE 表，则只显示匹配 LIKE 模式的 TABLE 表的索引。
.load FILE ?ENTRY? 加载一个扩展库。
.log FILE|off 开启或关闭日志。FILE 文件可以是 stderr（标准错误）/stdout（标准输出）。
.mode MODE 设置输出模式，MODE 可以是下列之一：csv 逗号分隔的值column 左对齐的列html HTML 的 代码insert TABLE 表的 SQL 插入（insert）语句line 每行一个值list 由 .separator 字符串分隔的值tabs 由 Tab 分隔的值tcl TCL 列表元素
.nullvalue STRING 在 NULL 值的地方输出 STRING 字符串。
.output FILENAME 发送输出到 FILENAME 文件。
.output stdout 发送输出到屏幕。
.print STRING... 逐字地输出 STRING 字符串。
.prompt MAIN CONTINUE 替换标准提示符。
.quit 退出 SQLite 提示符。
.read FILENAME 执行 FILENAME 文件中的 SQL。
.schema ?TABLE? 显示 CREATE 语句。如果指定了 TABLE 表，则只显示匹配 LIKE 模式的 TABLE 表。
.separator STRING 改变输出模式和 .import 所使用的分隔符。
.show 显示各种设置的当前值。
.stats ON|OFF 开启或关闭统计。
.tables ?PATTERN? 列出匹配 LIKE 模式的表的名称。
.timeout MS 尝试打开锁定的表 MS 毫秒。
.width NUM NUM 为 "column" 模式设置列宽度。
.timer ON|OFF 开启或关闭 CPU 定时器。

# 实战

# 格式化输出

sqlite>.header on
+sqlite>.mode column
+sqlite>.timer on
+sqlite>
+

# 输出结果到文件

sqlite> .mode list
+sqlite> .separator |
+sqlite> .output teyptest_file_1.txt
+sqlite> select * from tbl1;
+sqlite> .exit
+$ cat test_file_1.txt
+hello|10
+goodbye|20
+$
+

# SQLite JAVA Client

（1）在官方下载地址 (opens new window)下载 sqlite-jdbc-(VERSION).jar ，然后将 jar 包放在项目中的 classpath。

（2）通过 API 打开一个 SQLite 数据库连接。

执行方法：

> javac Sample.java
+> java -classpath ".;sqlite-jdbc-(VERSION).jar" Sample   # in Windows
+or
+> java -classpath ".:sqlite-jdbc-(VERSION).jar" Sample   # in Mac or Linux
+name = leo
+id = 1
+name = yui
+id = 2
+

示例：

public class Sample {
+    public static void main(String[] args) {
+        Connection connection = null;
+        try {
+            // 创建数据库连接
+            connection = DriverManager.getConnection("jdbc:sqlite:sample.db");
+            Statement statement = connection.createStatement();
+            statement.setQueryTimeout(30);  // 设置 sql 执行超时时间为 30s
+
+            statement.executeUpdate("drop table if exists person");
+            statement.executeUpdate("create table person (id integer, name string)");
+            statement.executeUpdate("insert into person values(1, 'leo')");
+            statement.executeUpdate("insert into person values(2, 'yui')");
+            ResultSet rs = statement.executeQuery("select * from person");
+            while (rs.next()) {
+                // 读取结果集
+                System.out.println("name = " + rs.getString("name"));
+                System.out.println("id = " + rs.getInt("id"));
+            }
+        } catch (SQLException e) {
+            // 如果错误信息是 "out of memory"，可能是找不到数据库文件
+            System.err.println(e.getMessage());
+        } finally {
+            try {
+                if (connection != null) {
+                    connection.close();
+                }
+            } catch (SQLException e) {
+                // 关闭连接失败
+                System.err.println(e.getMessage());
+            }
+        }
+    }
+}
+

# 如何指定数据库文件

Windows

Connection connection = DriverManager.getConnection("jdbc:sqlite:C:/work/mydatabase.db");
+

Unix (Linux, Mac OS X, etc)

Connection connection = DriverManager.getConnection("jdbc:sqlite:/home/leo/work/mydatabase.db");
+

# 如何使用内存数据库

Connection connection = DriverManager.getConnection("jdbc:sqlite::memory:");
+

# 参考资料

# 🚪 传送门

| 钝悟的博客 (opens new window) | db-tutorial 首页 (opens new window) |

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#SQLite
上次更新: 2023/06/29, 22:27:04
H2 应用指南
MongoDB 应用指南

+ ← + MongoDB 应用指南→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/c8cfeb/index.html b/pages/c8cfeb/index.html new file mode 100644 index 00000000..b8559e4c --- /dev/null +++ b/pages/c8cfeb/index.html @@ -0,0 +1,67 @@ + + + + + + HBase 数据模型 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2023-03-16
目录

HBase 数据模型

# HBase 数据模型

HBase 是一个面向 列 的数据库管理系统，这里更为确切的而说，HBase 是一个面向 列族 的数据库管理系统。表 schema 仅定义列族，表具有多个列族，每个列族可以包含任意数量的列，列由多个单元格（cell）组成，单元格可以存储多个版本的数据，多个版本数据以时间戳进行区分。

# HBase 逻辑存储结构

  • Table：Table 由 Row 和 Column 组成。
  • Row：Row 是列族（Column Family）的集合。
  • Row Key：Row Key 是用来检索记录的主键。 +
    • Row Key 是未解释的字节数组，所以理论上，任何数据都可以通过序列化表示成字符串或二进制，从而存为 HBase 的键值。
    • 表中的行，是按照 Row Key 的字典序进行排序。这里需要注意以下两点： +
      • 因为字典序对 Int 排序的结果是 1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。如果你使用整型的字符串作为行键，那么为了保持整型的自然序，行键必须用 0 作左填充。
      • 行的一次读写操作是原子性的 (不论一次读写多少列)。
    • 所有对表的访问都要通过 Row Key，有以下三种方式： +
      • 通过指定的 Row Key 进行访问；
      • 通过 Row Key 的 range 进行访问，即访问指定范围内的行；
      • 进行全表扫描。
  • Column Family：即列族。HBase 表中的每个列，都归属于某个列族。列族是表的 Schema 的一部分，所以列族需要在创建表时进行定义。 +
    • 一个表的列族必须作为表模式定义的一部分预先给出，但是新的列族成员可以随后按需加入。
    • 同一个列族的所有成员具有相同的前缀，例如 info:format，info:geo 都属于 info 这个列族。
  • Column Qualifier：列限定符。可以理解为是具体的列名，例如 info:format，info:geo 都属于 info 这个列族，它们的列限定符分别是 format 和 geo。列族和列限定符之间始终以冒号分隔。需要注意的是列限定符不是表 Schema 的一部分，你可以在插入数据的过程中动态创建列。
  • Column：HBase 中的列由列族和列限定符组成，由 :(冒号) 进行分隔，即一个完整的列名应该表述为 列族名 ：列限定符。
  • Cell：Cell 是行，列族和列限定符的组合，并包含值和时间戳。HBase 中通过 row key 和 column 确定的为一个存储单元称为 Cell，你可以等价理解为关系型数据库中由指定行和指定列确定的一个单元格，但不同的是 HBase 中的一个单元格是由多个版本的数据组成的，每个版本的数据用时间戳进行区分。 +
    • Cell 由行和列的坐标交叉决定，是有版本的。默认情况下，版本号是自动分配的，为 HBase 插入 Cell 时的时间戳。Cell 的内容是未解释的字节数组。
  • Timestamp：Cell 的版本通过时间戳来索引，时间戳的类型是 64 位整型，时间戳可以由 HBase 在数据写入时自动赋值，也可以由客户显式指定。每个 Cell 中，不同版本的数据按照时间戳倒序排列，即最新的数据排在最前面。

img

# HBase 物理存储结构

HBase 自动将表水平划分成区域（Region）。每个 Region 由表中 Row 的子集构成。每个 Region 由它所属的表的起始范围来表示（包含的第一行和最后一行）。初始时，一个表只有一个 Region，随着 Region 膨胀，当超过一定阈值时，会在某行的边界上分裂成两个大小基本相同的新 Region。在第一次划分之前，所有加载的数据都放在原始 Region 所在的那台服务器上。随着表变大，Region 个数也会逐渐增加。Region 是在 HBase 集群上分布数据的最小单位。

# HBase 数据模型示例

下图为 HBase 中一张表的：

  • RowKey 为行的唯一标识，所有行按照 RowKey 的字典序进行排序；
  • 该表具有两个列族，分别是 personal 和 office;
  • 其中列族 personal 拥有 name、city、phone 三个列，列族 office 拥有 tel、addres 两个列。

img

图片引用自 : HBase 是列式存储数据库吗 https://www.iteblog.com/archives/2498.html

# HBase 表特性

Hbase 的表具有以下特点：

  • 容量大：一个表可以有数十亿行，上百万列；
  • 面向列：数据是按照列存储，每一列都单独存放，数据即索引，在查询时可以只访问指定列的数据，有效地降低了系统的 I/O 负担；
  • 稀疏性：空 (null) 列并不占用存储空间，表可以设计的非常稀疏 ；
  • 数据多版本：每个单元中的数据可以有多个版本，按照时间戳排序，新的数据在最上面；
  • 存储类型：所有数据的底层存储格式都是字节数组 (byte[])。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#列式数据库#大数据#HBase
上次更新: 2023/06/29, 22:27:04
HBase 快速入门
HBase Schema 设计

+ ← + HBase Schema 设计→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase Java API 高级特性之协处理器 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/ca3ca5/index.html b/pages/ca3ca5/index.html new file mode 100644 index 00000000..c45494dd --- /dev/null +++ b/pages/ca3ca5/index.html @@ -0,0 +1,62 @@ + + + + + + Cassandra | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2019-08-22
目录

Cassandra

# Cassandra

Apache Cassandra 是一个高度可扩展的分区行存储。行被组织成具有所需主键的表。

最新版本：v4.0

# Quick Start

# 安装

先决条件

  • JDK8+
  • Python 2.7

# 简介

Apache Cassandra 是一套开源分布式 Key-Value 存储系统。它最初由 Facebook 开发，用于储存特别大的数据。

# 特性

# 主要特性

  • 分布式
  • 基于 column 的结构化
  • 高伸展性

Cassandra 的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对 Cassandra 的一个写操作，会被复制到其他节点上去，对 Cassandra 的读操作，也会被路由到某个节点上面去读取。对于一个 Cassandra 群集来说，扩展性能 是比较简单的事情，只管在群集里面添加节点就可以了。

# 突出特性

  • 模式灵活 - 使用 Cassandra，像文档存储，不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。这是一个惊人的效率提升，特别是在大型部署上。
  • 真正的可扩展性 - Cassandra 是纯粹意义上的水平扩展。为给集群添加更多容量，可以指向另一台电脑。你不必重启任何进程，改变应用查询，或手动迁移任何数据。
  • 多数据中心识别 - 你可以调整你的节点布局来避免某一个数据中心起火，一个备用的数据中心将至少有每条记录的完全复制。
  • 范围查询 - 如果你不喜欢全部的键值查询，则可以设置键的范围来查询。
  • 列表数据结构 - 在混合模式可以将超级列添加到 5 维。对于每个用户的索引，这是非常方便的。
  • 分布式写操作 - 有可以在任何地方任何时间集中读或写任何数据。并且不会有任何单点失败。

# 更多内容

# 🚪 传送门

| 钝悟的博客 (opens new window) | db-tutorial 首页 (opens new window) |

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#列式数据库#Cassandra
上次更新: 2023/06/29, 22:27:04
HBase 命令
Elasticsearch 面试总结

+ ← + Elasticsearch 面试总结→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/ca9888/index.html b/pages/ca9888/index.html new file mode 100644 index 00000000..6813d9af --- /dev/null +++ b/pages/ca9888/index.html @@ -0,0 +1,59 @@ + + + + + + 关系型数据库其他知识 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-04-11
目录

关系型数据库其他知识

# 关系型数据库其他知识

# 📖 内容

# 📚 资料

# 🚪 传送

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/ce5ca0/index.html b/pages/ce5ca0/index.html new file mode 100644 index 00000000..98c2f48c --- /dev/null +++ b/pages/ce5ca0/index.html @@ -0,0 +1,125 @@ + + + + + + HBase Java API 其他高级特性 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2023-03-31
目录

HBase Java API 其他高级特性

# HBase Java API 其他高级特性

# 计数器

HBase 提供了一种高级功能：计数器（counter）。HBase 计数器可以用于实时统计，无需延时较高的批量处理操作。HBase 有一种机制可以将列当作计数器：即读取并修改（其实就是一种 CAS 模式），其保证了在一次操作中的原子性。否则，用户需要对一行数据加锁，然后读取数据，再对当前数据做加法，最后写回 HBase 并释放行锁，这一系列操作会引起大量的资源竞争问题。

早期的 HBase 版本会在每次计数器更新操作调用一次 RPC 请求，新版本中可以在一次 RPC 请求中完成多个计数器的更新操作，但是多个计数器必须在同一行。

# 计数器使用 Shell 命令行

计数器不需要初始化，创建一个新列时初始值为 0，第一次 incr 操作返回 1。

计数器使用 incr 命令，增量可以是正数也可以是负数，但是必须是长整数 Long：

incr '<table>','<row>','<column>',['<increment-value>']
+

计数器使用的例子：

hbase(main):001:0> create 'counters','daily','weekly','monthly'
+0 row(s) in 1.2260 seconds
+
+hbase(main):002:0> incr 'counters','20190301','daily:hites',1
+COUNTER VALUE = 1
+
+hbase(main):003:0> incr'counters','20190301','daily:hites',1
+COUNTER VALUE = 2
+
+hbase(main):004:0> get_counter 'counters','20190301','daily:hites'
+COUNTER VALUE = 2
+

需要注意的是，增加的参数必须是长整型 Long，如果按照错误的格式更新了计数器（如字符串格式），下次调用 incr 会得到错误的结果：

hbase(main):005:0> put 'counters','20190301','daily:clicks','1'
+0 row(s) in 1.3250 seconds
+
+hbase(main):006:0> incr'counters','20190301','daily:clicks',1
+COUNTER VALUE = 3530822107858468865
+

# 单计数器

操作一个计数器，类似 shell 命令 incr

HTable table  = new HTable(conf, "counters");
+
+long cnt1 = table.incrementColumnValue(Bytes.toBytes("20190301"),
+    Bytes.toBytes("daily"),
+    Bytes.toBytes("hits"),
+    1L);
+
+long cnt2 = table.incrementColumnValue(Bytes.toBytes("20190301"),
+    Bytes.toBytes("daily"),
+    Bytes.toBytes("hits"),
+    1L);
+
+long current = table.incrementColumnValue(Bytes.toBytes("20190301"),
+    Bytes.toBytes("daily"),
+    Bytes.toBytes("hits"),
+    0);
+

# 多计数器

使用 Table 的 increment() 方法可以操作一行的多个计数器，需要构建 Increment 实例，并且指定行键：

HTable table  = new HTable(conf, "counters");
+
+Increment incr1 = new Increment(Bytes.toBytes("20190301"));
+incr1.addColumn(Bytes.toBytes("daily"), Bytes.toBytes("clicks"),1);
+incr1.addColumn(Bytes.toBytes("daily"), Bytes.toBytes("hits"), 1);
+incr1.addColumn(Bytes.toBytes("weekly"), Bytes.toBytes("clicks"), 2);
+incr1.addColumn(Bytes.toBytes("weekly"), Bytes.toBytes("hits"), 2);
+
+Result result = table.increment(incr1);
+for(Cell cell : result.rawCells()) {
+    // ...
+}
+

Increment 类还有一种构造器：

Increment(byte[] row, RowLock rowLock)
+

rowLock 参数可选，可以设置用户自定义锁，可以限制其他写程序操作此行，但是不保证读的操作性。

# 连接管理

# 连接管理简介

在 HBase Java API 中，Connection 类代表了一个集群连接，封装了与多台服务器（Matser/Region Server）的底层连接以及与 zookeeper 的连接。Connection 通过 ConnectionFactory 类实例化，而连接的生命周期则由调用者管理，调用者必须显示调用 close() 来释放连接。Connection 是线程安全的。创建 Connection 实例的开销很高，因此一个进程只需要实例化一个 Connection 即可。

Table 接口用于对指定的 HBase 表进行 CRUD 操作。一般，通过 Connection 获取 Table 实例，用完后，调用 close() 释放连接。

Admin 接口主要用于创建、删除、查看、启用/禁用 HBase 表，以及一些其他管理操作。一般，通过 Connection 获取 Admin 实例，用完后，调用 close() 释放连接。

Table 和 Admin 实例都是轻量级且并非线程安全的。建议每个线程只实例化一个 Table 或 Admin 实例。

# 连接池

问题：HBase 为什么没有提供 Connection 的连接池来获取更好的性能？是否需要自定义 Connection 连接池？

答：不需要。官方对于 Connection 的使用说明中，明确指出：对于高并发多线程访问的应用程序，一个进程中只需要预先创建一个 Connection。

问题：HBase 老版本中 HTablePool 为什么废弃？是否需要自定义 Table 的连接池？

答：不需要。Table 和 Admin 的连接本质上是复用 Connection，实例化是一个较为轻量级的操作，因此，并不需要缓存或池化。实际上，HBase Java API 官方就是这么建议的。

下面是管理 HBase 连接的一个正确编程模型

// 所有进程共用一个 connection 对象
+connection = ConnectionFactory.createConnection(config);
+
+// 每个线程使用单独的 table 对象
+Table table = connection.getTable(TableName.valueOf("tableName"));
+try {
+	...
+} finally {
+   table.close();
+}
+
+Admin admin = connection.getAdmin();
+try {
+	...
+} finally {
+   admin.close();
+}
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#大数据#HBase#API
上次更新: 2023/06/29, 22:27:04
HBase Java API 高级特性之协处理器
HBase Java API 管理功能

+ ← + HBase Java API 管理功能→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase 数据模型 +
03-16
03
+ HBase Java API 高级特性之协处理器 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/d1bae4/index.html b/pages/d1bae4/index.html new file mode 100644 index 00000000..58620c6d --- /dev/null +++ b/pages/d1bae4/index.html @@ -0,0 +1,134 @@ + + + + + + Elasticsearch 映射 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-05-16
目录

Elasticsearch 映射

# Elasticsearch 映射

在 Elasticsearch 中，Mapping（映射），用来定义一个文档以及其所包含的字段如何被存储和索引，可以在映射中事先定义字段的数据类型、字段的权重、分词器等属性，就如同在关系型数据库中创建数据表时会设置字段的类型。

Mapping 会把 JSON 文档映射成 Lucene 所需要的扁平格式

一个 Mapping 属于一个索引的 Type

  • 每个文档都属于一个 Type
  • 一个 Type 有一个 Mapping 定义
  • 7.0 开始，不需要在 Mapping 定义中指定 type 信息

每个 document 都是 field 的集合，每个 field 都有自己的数据类型。映射数据时，可以创建一个 mapping，其中包含与 document 相关的 field 列表。映射定义还包括元数据 field，例如 _source ，它自定义如何处理 document 的关联元数据。

# 映射方式

在 Elasticsearch 中，映射可分为静态映射和动态映射。在关系型数据库中写入数据之前首先要建表，在建表语句中声明字段的属性，在 Elasticsearch 中，则不必如此，Elasticsearch 最重要的功能之一就是让你尽可能快地开始探索数据，文档写入 Elasticsearch 中，它会根据字段的类型自动识别，这种机制称为动态映射，而静态映射则是写入数据之前对字段的属性进行手工设置。

# 静态映射

ES 官方将静态映射称为显式映射（Explicit mapping (opens new window)）。静态映射是在创建索引时显示的指定索引映射。静态映射和 SQL 中在建表语句中指定字段属性类似。相比动态映射，通过静态映射可以添加更详细、更精准的配置信息。例如：

  • 哪些字符串字段应被视为全文字段。
  • 哪些字段包含数字、日期或地理位置。
  • 日期值的格式。
  • 用于控制动态添加字段的自定义规则。

【示例】创建索引时，显示指定 mapping

PUT /my-index-000001
+{
+  "mappings": {
+    "properties": {
+      "age":    { "type": "integer" },
+      "email":  { "type": "keyword"  },
+      "name":   { "type": "text"  }
+    }
+  }
+}
+

【示例】在已存在的索引中，指定一个 field 的属性

PUT /my-index-000001/_mapping
+{
+  "properties": {
+    "employee-id": {
+      "type": "keyword",
+      "index": false
+    }
+  }
+}
+

【示例】查看 mapping

GET /my-index-000001/_mapping
+

【示例】查看指定 field 的 mapping

GET /my-index-000001/_mapping/field/employee-id
+

# 动态映射

动态映射机制，允许用户不手动定义映射，Elasticsearch 会自动识别字段类型。在实际项目中，如果遇到的业务在导入数据之前不确定有哪些字段，也不清楚字段的类型是什么，使用动态映射非常合适。当 Elasticsearch 在文档中碰到一个以前没见过的字段时，它会利用动态映射来决定该字段的类型，并自动把该字段添加到映射中。

示例：创建一个名为 data 的索引、其 mapping 类型为 _doc，并且有一个类型为 long 的字段 count。

PUT data/_doc/1
+{ "count": 5 }
+

# 动态字段映射

动态字段映射（Dynamic field mappings (opens new window)）是用于管理动态字段检测的规则。当 Elasticsearch 在文档中检测到新字段时，默认情况下会动态将该字段添加到类型映射中。

在 mapping 中可以通过将 dynamic (opens new window) 参数设置为 true 或 runtime 来开启动态映射。

dynamic (opens new window) 不同设置的作用：

可选值 说明
true 新字段被添加到 mapping 中。mapping 的默认设置。
runtime 新字段被添加到 mapping 中并作为运行时字段——这些字段不会被索引，但是可以在查询时出现在 _source 中。
false 新字段不会被索引或搜索，但仍会出现在返回匹配的 _source 字段中。这些字段不会添加到映射中，并且必须显式添加新字段。
strict 如果检测到新字段，则会抛出异常并拒绝文档。必须将新字段显式添加到映射中。

需要注意的是：对已有字段，一旦已经有数据写入，就不再支持修改字段定义。如果希望改变字段类型，必须重建索引。这是由于 Lucene 实现的倒排索引，一旦生成后，就不允许修改。如果修改了字段的数据类型，会导致已被索引的字段无法被搜索。

启用动态字段映射后，Elasticsearch 使用内置规则来确定如何映射每个字段的数据类型。规则如下：

JSON 数据类型 "dynamic":"true" "dynamic":"runtime"
null 没有字段被添加 没有字段被添加
true or false boolean 类型 boolean 类型
浮点型数字 float 类型 double 类型
数字 数字型 long 类型
JSON 对象 object 类型 没有字段被添加
数组 由数组中第一个非空值决定 由数组中第一个非空值决定
开启日期检测 (opens new window)的字符串 date 类型 date 类型
开启数字检测 (opens new window)的字符串 float 类型或 long类型 double 类型或 long 类型
什么也没开启的字符串 带有 .keyword 子 field 的 text 类型 keyword 类型

下面举一个例子认识动态 mapping，在 Elasticsearch 中创建一个新的索引并查看它的 mapping，命令如下：

PUT books
+GET books/_mapping
+

此时 books 索引的 mapping 是空的，返回结果如下：

{
+  "books": {
+    "mappings": {}
+  }
+}
+

再往 books 索引中写入一条文档，命令如下：

PUT books/it/1
+{
+	"id": 1,
+	"publish_date": "2019-11-10",
+	"name": "master Elasticsearch"
+}
+

文档写入完成之后，再次查看 mapping，返回结果如下：

{
+  "books": {
+    "mappings": {
+      "properties": {
+        "id": {
+          "type": "long"
+        },
+        "name": {
+          "type": "text",
+          "fields": {
+            "keyword": {
+              "type": "keyword",
+              "ignore_above": 256
+            }
+          }
+        },
+        "publish_date": {
+          "type": "date"
+        }
+      }
+    }
+  }
+}
+

动态映射有时可能会错误的识别字段类型，这种情况下，可能会导致一些功能无法正常使用，如 Range 查询。所以，使用动态 mapping 要结合实际业务需求来综合考虑，如果将 Elasticsearch 当作主要的数据存储使用，并且希望出现未知字段时抛出异常来提醒你注意这一问题，那么开启动态 mapping 并不适用。

# 动态模板

**动态模板（dynamic templates (opens new window)）**是用于给 mapping 动态添加字段的自定义规则。

动态模板可以设置匹配条件，只有匹配的情况下才使用动态模板：

  • match_mapping_type 对 Elasticsearch 检测到的数据类型进行操作
  • match 和 unmatch 使用模式匹配字段名称
  • path_match 和 path_unmatch 对字段的完整虚线路径进行操作
  • 如果动态模板没有定义 match_mapping_type、match 或 path_match，则不会匹配任何字段。您仍然可以在批量请求的 dynamic_templates 部分按名称引用模板。

【示例】当设置 'dynamic':'true' 时，Elasticsearch 会将字符串字段映射为带有关键字子字段的文本字段。如果只是索引结构化内容并且对全文搜索不感兴趣，可以让 Elasticsearch 仅将字段映射为关键字字段。这种情况下，只有完全匹配才能搜索到这些字段。

PUT my-index-000001
+{
+  "mappings": {
+    "dynamic_templates": [
+      {
+        "strings_as_keywords": {
+          "match_mapping_type": "string",
+          "mapping": {
+            "type": "keyword"
+          }
+        }
+      }
+    ]
+  }
+}
+

# 运行时字段

运行时字段是在查询时评估的字段。运行时字段有以下作用：

  • 在不重新索引数据的情况下，向现有文档添加字段
  • 在不了解数据结构的情况下，也可以处理数据
  • 在查询时覆盖从索引字段返回的值
  • 为特定用途定义字段而不修改底层架构

检索 Elasticsearch 时，运行时字段和其他字段并没有什么不同。

需要注意的是：使用 _search API 上的 fields 参数来检索运行时字段的值。运行时字段不会显示在 _source 中，但 fields API 适用于所有字段，即使是那些未作为原始 _source 的一部分发送的字段。

运行时字段在处理日志数据时很有用，尤其是当日志是不确定的数据结构时：这种情况下，会降低搜索速度，但您的索引大小要小得多，您可以更快地处理日志，而无需为它们设置索引。

# 运行时字段的优点

因为运行时字段没有被索引，所以添加运行时字段不会增加索引大小。用户可以直接在 mapping 中定义运行时字段，从而节省存储成本并提高采集数据的速度。定义了运行时字段后，可以立即在搜索请求、聚合、过滤和排序中使用它。

如果将运行时字段设为索引字段，则无需修改任何引用运行时字段的查询。更好的是，您可以引用字段是运行时字段的一些索引，以及字段是索引字段的其他索引。您可以灵活地选择要索引哪些字段以及保留哪些字段作为运行时字段。

就其核心而言，运行时字段最重要的好处是能够在您提取字段后将字段添加到文档中。此功能简化了映射决策，因为您不必预先决定如何解析数据，并且可以使用运行时字段随时修改映射。使用运行时字段允许更小的索引和更快的摄取时间，这结合使用更少的资源并降低您的运营成本。

# 字段数据类型

在 Elasticsearch 中，每个字段都有一个字段数据类型或字段类型，用于指示字段包含的数据类型（例如字符串或布尔值）及其预期用途。字段类型按系列分组。同一族中的类型具有完全相同的搜索行为，但可能具有不同的空间使用或性能特征。

Elasticsearch 提供了非常丰富的数据类型，官方将其分为以下几类：

# 元数据字段

一个文档中，不仅仅包含数据 ，也包含元数据。元数据是用于描述文档的信息。

# 映射参数

Elasticsearch 提供了以下映射参数：

  • analyzer (opens new window)：指定在索引或搜索文本字段时用于文本分析的分析器。
  • coerce (opens new window)：如果开启，Elasticsearch 将尝试清理脏数据以适应字段的数据类型。
  • copy_to (opens new window)：允许将多个字段的值复制到一个组字段中，然后可以将其作为单个字段进行查询。
  • doc_values (opens new window)：默认情况下，所有字段都是被
  • dynamic (opens new window)：是否开启动态映射。
  • eager_global_ordinals (opens new window)：当在 global ordinals 的时候，refresh 以后下一次查询字典就需要重新构建，在追求查询的场景下很影响查询性能。可以使用 eager_global_ordinals，即在每次 refresh 以后即可更新字典，字典常驻内存，减少了查询的时候构建字典的耗时。
  • enabled (opens new window)：只能应用于顶级 mapping 定义和 object 字段。设置为 false 后，Elasticsearch 解析时，会完全跳过该字段。
  • fielddata (opens new window)：默认情况下， text 字段是可搜索的，但不可用于聚合、排序或脚本。如果为字段设置 fielddata=true，就会通过反转倒排索引将 fielddata 加载到内存中。请注意，这可能会占用大量内存。如果想对 text 字段进行聚合、排序或脚本操作，fielddata 是唯一方法。
  • fields (opens new window)：有时候，同一个字段需要以不同目的进行索引，此时可以通过 fields 进行配置。
  • format (opens new window)：用于格式化日期类型。
  • ignore_above (opens new window)：字符串长度大于 ignore_above 所设，则不会被索引或存储。
  • ignore_malformed (opens new window)：有时候，同一个字段，可能会存储不同的数据类型。默认情况下，Elasticsearch 解析字段数据类型失败时，会引发异常，并拒绝整个文档。 如果设置 ignore_malformed 为 true，则允许忽略异常。这种情况下，格式错误的字段不会被索引，但文档中的其他字段可以正常处理。
  • index_options (opens new window) 用于控制将哪些信息添加到倒排索引以进行搜索和突出显示。只有 text 和 keyword 等基于术语（term）的字段类型支持此配置。
  • index_phrases (opens new window)：如果启用，两个词的组合（shingles）将被索引到一个单独的字段中。这允许以更大的索引为代价，更有效地运行精确的短语查询（无 slop）。请注意，当停用词未被删除时，此方法效果最佳，因为包含停用词的短语将不使用辅助字段，并将回退到标准短语查询。接受真或假（默认）。
  • index_prefixes (opens new window)：index_prefixes 参数启用 term 前缀索引以加快前缀搜索。
  • index (opens new window)：index 选项控制字段值是否被索引。默认为 true。
  • meta (opens new window)：附加到字段的元数据。此元数据对 Elasticsearch 是不透明的，它仅适用于多个应用共享相同索引的元数据信息，例如：单位。
  • normalizer (opens new window)：keyword 字段的 normalizer 属性类似于 analyzer (opens new window) ，只是它保证分析链只产生单个标记。 normalizer 在索引 keyword 之前应用，以及在搜索时通过查询解析器（例如匹配查询）或通过术语级别查询（例如术语查询）搜索关键字字段时应用。
  • norms (opens new window)：norms 存储在查询时使用的各种规范化因子，以便计算文档的相关性评分。
  • null_value (opens new window)：null 值无法被索引和搜索。当一个字段被设为 null，则被视为没有值。null_value 允许将空值替换为指定值，以便对其进行索引和搜索。
  • position_increment_gap (opens new window)：分析的文本字段会考虑术语位置，以便能够支持邻近或短语查询。当索引具有多个值的文本字段时，值之间会添加一个“假”间隙，以防止大多数短语查询在值之间匹配。此间隙的大小使用 position_increment_gap 配置，默认为 100。
  • properties (opens new window)：类型映射、对象字段和嵌套字段包含的子字段，都称为属性。这些属性可以是任何数据类型，包括对象和嵌套。
  • search_analyzer (opens new window)：通常，在索引时和搜索时应使用相同的分析器，以确保查询中的术语与倒排索引中的术语格式相同。但是，有时在搜索时使用不同的分析器可能是有意义的，例如使用 edge_ngram (opens new window) 标记器实现自动补全或使用同义词搜索时。
  • similarity (opens new window)：Elasticsearch 允许为每个字段配置文本评分算法或相似度。相似度设置提供了一种选择文本相似度算法的简单方法，而不是默认的 BM25，例如布尔值。只有 text 和 keyword 等基于文本的字段类型支持此配置。
  • store (opens new window)：默认情况下，对字段值进行索引以使其可搜索，但不会存储它们。这意味着可以查询该字段，但无法检索原始字段值。通常这不重要，字段值已经是默认存储的 _source 字段的一部分。如果您只想检索单个字段或几个字段的值，而不是整个 _source，则可以通过 source filtering (opens new window) 来实现。
  • term_vector (opens new window)：term_vector 包含有关分析过程产生的术语的信息，包括： +
    • 术语列表
    • 每个 term 的位置（或顺序）
    • 起始和结束字符偏移量，用于将 term 和原始字符串进行映射
    • 有效负载（如果可用） - 用户定义的，与 term 位置相关的二进制数据

# 映射配置

  • index.mapping.total_fields.limit：索引中的最大字段数。字段和对象映射以及字段别名计入此限制。默认值为 1000。
  • index.mapping.depth.limit：字段的最大深度，以内部对象的数量来衡量。例如，如果所有字段都在根对象级别定义，则深度为 1。如果有一个对象映射，则深度为 2，以此类推。默认值为 20。
  • index.mapping.nested_fields.limit：索引中不同 nested 映射的最大数量。 nested 类型只应在特殊情况下使用，即需要相互独立地查询对象数组。为了防止设计不佳的映射，此设置限制了每个索引的唯一 nested 类型的数量。默认值为 50。
  • index.mapping.nested_objects.limit：单个文档中，所有 nested 类型中包含的最大嵌套 JSON 对象数。当文档包含太多 nested 对象时，此限制有助于防止出现内存溢出。默认值为 10000。
  • index.mapping.field_name_length.limit：设置字段名称的最大长度。默认为 Long.MAX_VALUE（无限制）。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#索引
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/d7cd88/index.html b/pages/d7cd88/index.html new file mode 100644 index 00000000..5ba171a6 --- /dev/null +++ b/pages/d7cd88/index.html @@ -0,0 +1,65 @@ + + + + + + 数据结构与数据库索引 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-03-27
目录

数据结构与数据库索引

# 数据结构与数据库索引

关键词：链表、数组、散列表、红黑树、B+ 树、LSM 树、跳表

# 引言

数据库是“按照 数据结构 来组织、存储和管理数据的仓库”。是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合。

——上面这句定义对数据库的定义来自百度百科。通过这个定义，我们也能明显看出数据结构是实现数据库的基石。

从本质来看，数据库只负责两件事：读数据、写数据；而数据结构研究的是如何合理组织数据，尽可能提升读、写数据的效率，这恰好是数据库的核心问题。因此，数据结构与数据库这两个领域有非常多的交集。其中，数据库索引最能体现二者的紧密关联。

索引是数据库为了提高查找效率的一种数据结构。索引基于原始数据衍生而来，它的主要作用是缩小检索的数据范围，提升查询性能。通俗来说，索引在数据库中的作用就像是一本书的目录索引。索引对于良好的性能非常关键，在数据量小且负载较低时，不恰当的索引对于性能的影响可能还不明显；但随着数据量逐渐增大，性能则会急剧下降。因此，索引优化应该是查询性能优化的最有效手段。

很多数据库允许单独添加和删除索引，而不影响数据库的内容，它只会影响查询性能。维护额外的结构势必会引入开销，特别是在新数据写入时。对于写入，它很难超过简单地追加文件方式的性能，因为那已经是最简单的写操作了。由于每次写数据时，需要更新索引，因此任何类型的索引通常都会降低写的速度。

本文以一些常见的数据库为例，分析它们的索引采用了什么样的数据结构，有什么利弊，为何如此设计。

# 数组和链表

数组和链表分别代表了连续空间和不连续空间的存储方式，它们是线性表（Linear List）的典型代表。其他所有的数据结构，比如栈、队列、二叉树、B+ 树等，实际上都是这两者的结合和变化。

数组用连续的内存空间来存储数据。数组支持随机访问，根据下标随机访问的时间复杂度为 O(1)。但这并不代表数组的查找时间复杂度也是 O(1)。

  • 对于无序数组，只能顺序查找，其时间复杂度为 O(n)。
  • 对于有序数组，可以应用二分查找法，其时间复杂度为 O(log n)。

在有序数组上应用二分查找法如此高效，为什么几乎没有数据库直接使用数组作为索引？这是因为它的限制条件：数据有序——为了保证数据有序，每次添加、删除数组数据时，都必须要进行数据调整，来保证其有序，而 数组的插入/删除操作，时间复杂度为 O(n)。此外，由于数组空间大小固定，每次扩容只能采用复制数组的方式。数组的这些特性，决定了它不适合用于数据频繁变化的应用场景。

img

链表用不连续的内存空间来存储数据；并通过一个指针按顺序将这些空间串起来，形成一条链。

区别于数组，链表中的元素不是存储在内存中连续的一片区域，链表中的数据存储在每一个称之为「结点」复合区域里，在每一个结点除了存储数据以外，还保存了到下一个节点的指针（Pointer）。由于不必按顺序存储，链表的插入/删除操作，时间复杂度为 O(1)，但是，链表只支持顺序访问，其 查找时间复杂度为 O(n)。其低效的查找方式，决定了链表不适合作为索引。

img

# 哈希索引

哈希表是一种以键 - 值（key-value）对形式存储数据的结构，我们只要输入待查找的值即 key，就可以找到其对应的值即 Value。

哈希表 使用 哈希函数 组织数据，以支持快速插入和搜索的数据结构。哈希表的本质是一个数组，其思路是：使用 Hash 函数将 Key 转换为数组下标，利用数组的随机访问特性，使得我们能在 O(1) 的时间代价内完成检索。

img

有两种不同类型的哈希表：哈希集合 和 哈希映射。

  • 哈希集合 是集合数据结构的实现之一，用于存储非重复值。
  • 哈希映射 是映射 数据结构的实现之一，用于存储键值对。

哈希索引基于哈希表实现，只适用于等值查询。对于每一行数据，哈希索引都会将所有的索引列计算一个哈希码（hashcode），哈希码是一个较小的值。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针。

✔ 哈希索引的优点：

  • 因为索引数据结构紧凑，所以查询速度非常快。

❌ 哈希索引的缺点：

  • 哈希索引值包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，所以大部分情况下这一点对性能影响不大。
  • 哈希索引数据不是按照索引值顺序存储的，所以无法用于排序。
  • 哈希索引不支持部分索引匹配查找，因为哈希索引时使用索引列的全部内容来进行哈希计算的。如，在数据列 (A,B) 上建立哈希索引，如果查询只有数据列 A，无法使用该索引。
  • 哈希索引只支持等值比较查询，包括 =、IN()、<=>；不支持任何范围查询，如 WHERE price > 100。
  • 哈希索引有可能出现哈希冲突
    • 出现哈希冲突时，必须遍历链表中所有的行指针，逐行比较，直到找到符合条件的行。
    • 如果哈希冲突多的话，维护索引的代价会很高。

因为种种限制，所以哈希索引只适用于特定的场合。而一旦使用哈希索引，则它带来的性能提升会非常显著。例如，Mysql 中的 Memory 存储引擎就显示的支持哈希索引。

# B-Tree 索引

通常我们所说的 B 树索引是指 B-Tree 索引，它是目前关系型数据库中查找数据最为常用和有效的索引，大多数存储引擎都支持这种索引。使用 B-Tree 这个术语，是因为 MySQL 在 CREATE TABLE 或其它语句中使用了这个关键字，但实际上不同的存储引擎可能使用不同的数据结构，比如 InnoDB 使用的是 B+Tree索引；而 MyISAM 使用的是 B-Tree索引。

B-Tree 索引中的 B 是指 balance，意为平衡。需要注意的是，B-Tree 索引并不能找到一个给定键值的具体行，它找到的只是被查找数据行所在的页，接着数据库会把页读入到内存，再在内存中进行查找，最后得到要查找的数据。

# 二叉搜索树

二叉搜索树的特点是：每个节点的左儿子小于父节点，父节点又小于右儿子。其查询时间复杂度是 O(log n)。

当然为了维持 O(log n) 的查询复杂度，你就需要保持这棵树是平衡二叉树。为了做这个保证，更新的时间复杂度也是 O(log n)。

随着数据库中数据的增加，索引本身大小随之增加，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。这样的话，索引查找过程中就要产生磁盘 I/O 消耗，相对于内存存取，I/O 存取的消耗要高几个数量级。可以想象一下一棵几百万节点的二叉树的深度是多少？如果将这么大深度的一颗二叉树放磁盘上，每读取一个节点，需要一次磁盘的 I/O 读取，整个查找的耗时显然是不能够接受的。那么如何减少查找过程中的 I/O 存取次数？

一种行之有效的解决方法是减少树的深度，将二叉树变为 N 叉树（多路搜索树），而 B+ 树就是一种多路搜索树。

# B+Tree 索引

B+ 树索引适用于全键值查找、键值范围查找和键前缀查找，其中键前缀查找只适用于最左前缀查找。

理解 B+Tree，只需要理解其最重要的两个特征即可：

  • 第一，所有的关键字（可以理解为数据）都存储在叶子节点，非叶子节点并不存储真正的数据，所有记录节点都是按键值大小顺序存放在同一层叶子节点上。
  • 其次，所有的叶子节点由指针连接。如下图为简化了的B+Tree。

img

根据叶子节点的内容，索引类型分为主键索引和非主键索引。

  • 聚簇索引（clustered）：又称为主键索引，其叶子节点存的是整行数据。因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。InnoDB 的聚簇索引实际是在同一个结构中保存了 B 树的索引和数据行。
  • 非主键索引的叶子节点内容是主键的值。在 InnoDB 里，非主键索引也被称为二级索引（secondary）。数据存储在一个位置，索引存储在另一个位置，索引中包含指向数据存储位置的指针。可以有多个，小于 249 个。

聚簇表示数据行和相邻的键值紧凑地存储在一起，因为数据紧凑，所以访问快。因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。

聚簇索引和非聚簇索引的查询有什么区别

  • 如果语句是 select * from T where ID=500，即聚簇索引查询方式，则只需要搜索 ID 这棵 B+ 树；
  • 如果语句是 select * from T where k=5，即非聚簇索引查询方式，则需要先搜索 k 索引树，得到 ID 的值为 500，再到 ID 索引树搜索一次。这个过程称为回表。

也就是说，基于非聚簇索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。

显然，主键长度越小，非聚簇索引的叶子节点就越小，非聚簇索引占用的空间也就越小。

自增主键是指自增列上定义的主键，在建表语句中一般是这么定义的： NOT NULL PRIMARY KEY AUTO_INCREMENT。从性能和存储空间方面考量，自增主键往往是更合理的选择。有没有什么场景适合用业务字段直接做主键的呢？还是有的。比如，有些业务的场景需求是这样的：

  • 只有一个索引；
  • 该索引必须是唯一索引。

由于没有其他索引，所以也就不用考虑其他索引的叶子节点大小的问题。这时候我们就要优先考虑上一段提到的“尽量使用主键查询”原则，直接将这个索引设置为主键，可以避免每次查询需要搜索两棵树。

内存是半导体元件。对于内存而言，只要给出了内存地址，我们就可以直接访问该地址取出数据。这个过程具有高效的随机访问特性，因此内存也叫随机访问存储器（Random Access Memory，即 RAM）。内存的访问速度很快，但是价格相对较昂贵，因此一般的计算机内存空间都相对较小。

而磁盘是机械器件。磁盘访问数据时，需要等磁盘盘片旋转到磁头下，才能读取相应的数据。尽管磁盘的旋转速度很快，但是和内存的随机访问相比，性能差距非常大。一般来说，如果是随机读写，会有 10 万到 100 万倍左右的差距。但如果是顺序访问大批量数据的话，磁盘的性能和内存就是一个数量级的。

磁盘的最小读写单位是扇区，较早期的磁盘一个扇区是 512 字节。随着磁盘技术的发展，目前常见的磁盘扇区是 4K 个字节。操作系统一次会读写多个扇区，所以操作系统的最小读写单位是块（Block），也叫作簇（Cluster）。当我们要从磁盘中读取一个数据时，操作系统会一次性将整个块都读出来。因此，对于大批量的顺序读写来说，磁盘的效率会比随机读写高许多。

假设有一个有序数组存储在硬盘中，如果它足够大，那么它会存储在多个块中。当我们要对这个数组使用二分查找时，需要先找到中间元素所在的块，将这个块从磁盘中读到内存里，然后在内存中进行二分查找。如果下一步要读的元素在其他块中，则需要再将相应块从磁盘中读入内存。直到查询结束，这个过程可能会多次访问磁盘。我们可以看到，这样的检索性能非常低。

由于磁盘相对于内存而言访问速度实在太慢，因此，对于磁盘上数据的高效检索，我们有一个极其重要的原则：对磁盘的访问次数要尽可能的少！

将索引和数据分离就是一种常见的设计思路。在数据频繁变化的场景中，有序数组并不是一个最好的选择，二叉检索树或者哈希表往往更有普适性。但是，哈希表由于缺乏范围检索的能力，在一些场合也不适用。因此，二叉检索树这种树形结构是许多常见检索系统的实施方案。

随着索引数据越来越大，直到无法完全加载到内存中，这是需要将索引数据也存入磁盘中。B+ 树给出了将树形索引的所有节点都存在磁盘上的高效检索方案。操作系统对磁盘数据的访问是以块为单位的。因此，如果我们想将树型索引的一个节点从磁盘中读出，即使该节点的数据量很小（比如说只有几个字节），但磁盘依然会将整个块的数据全部读出来，而不是只读这一小部分数据，这会让有效读取效率很低。B+ 树的一个关键设计，就是让一个节点的大小等于一个块的大小。节点内存储的数据，不是一个元素，而是一个可以装 m 个元素的有序数组。这样一来，我们就可以将磁盘一次读取的数据全部利用起来，使得读取效率最大化。

B+ 树还有另一个设计，就是将所有的节点分为内部节点和叶子节点。内部节点仅存储 key 和维持树形结构的指针，并不存储 key 对应的数据（无论是具体数据还是文件位置信息）。这样内部节点就能存储更多的索引数据，我们也就可以使用最少的内部节点，将所有数据组织起来了。而叶子节点仅存储 key 和对应数据，不存储维持树形结构的指针。通过这样的设计，B+ 树就能做到节点的空间利用率最大化。此外，B+ 树还将同一层的所有节点串成了有序的双向链表，这样一来，B+ 树就同时具备了良好的范围查询能力和灵活调整的能力了。

因此，B+ 树是一棵完全平衡的 m 阶多叉树。所谓的 m 阶，指的是每个节点最多有 m 个子节点，并且每个节点里都存了一个紧凑的可包含 m 个元素的数组。

即使是复杂的 B+ 树，我们将它拆解开来，其实也是由简单的数组、链表和树组成的，而且 B+ 树的检索过程其实也是二分查找。因此，如果 B+ 树完全加载在内存中的话，它的检索效率其实并不会比有序数组或者二叉检索树更 +高，也还是二分查找的 log(n) 的效率。并且，它还比数组和二叉检索树更加复杂，还会带来额外的开销。

另外，这一节还有一个很重要的设计思想需要你掌握，那就是将索引和数据分离。通过这样的方式，我们能将索引的数组大小保持在一个较小的范围内，让它能加载在内存中。在许多大规模系统中，都是使用这个设计思想来精简索引的。而且，B+ 树的内部节点和叶子节点的区分，其实也是索引和数据分离的一次实践。

MySQL 中的 B+ 树实现其实有两种，一种是 MyISAM 引擎，另一种是 InnoDB 引擎。它们的核心区别就在于，数据和索引是否是分离的。

在 MyISAM 引擎中，B+ 树的叶子节点仅存储了数据的位置指针，这是一种索引和数据分离的设计方案，叫作非聚集索引。如果要保证 MyISAM 的数据一致性，那我们需要在表级别上进行加锁处理。

在 InnoDB 中，B+ 树的叶子节点直接存储了具体数据，这是一种索引和数据一体的方案。叫作聚集索引。由于数据直接就存在索引的叶子节点中，因此 InnoDB 不需要给全表加锁来保证一致性，它只需要支持行级的锁就可以了。

# LSM 树

B+ 树的数据都存储在叶子节点中，而叶子节点一般都存储在磁盘中。因此，每次插入的新数据都需要随机写入磁盘，而随机写入的性能非常慢。如果是一个日志系统，每秒钟要写入上千条甚至上万条数据，这样的磁盘操作代价会使得系统性能急剧下降，甚至无法使用。

操作系统对磁盘的读写是以块为单位的，我们能否以块为单位写入，而不是每次插入一个数据都要随机写入磁盘呢？这样是不是就可以大幅度减少写入操作了呢？解决方案就是：LSM 树（Log Structured Merge Trees）。

LSM 树就是根据这个思路设计了这样一个机制：当数据写入时，延迟写磁盘，将数据先存放在内存中的树里，进行常规的存储和查询。当内存中的树持续变大达到阈值时，再批量地以块为单位写入磁盘的树中。因此，LSM 树至少需要由两棵树组成，一棵是存储在内存中较小的 C0 树，另一棵是存储在磁盘中较大的 C1 树。

LSM 树具有以下 3 个特点：

  1. 将索引分为内存和磁盘两部分，并在内存达到阈值时启动树合并（Merge Trees）；
  2. 用批量写入代替随机写入，并且用预写日志 WAL 技术（Write AheadLog，预写日志技术）保证内存数据，在系统崩溃后可以被恢复；
  3. 数据采取类似日志追加写的方式写入（Log Structured）磁盘，以顺序写的方式提高写 +入效率。

LSM 树的这些特点，使得它相对于 B+ 树，在写入性能上有大幅提升。所以，许多 NoSQL 系统都使用 LSM 树作为检索引擎，而且还对 LSM 树进行了优化以提升检索性能。

# 倒排索引

倒排索引的核心其实并不复杂，它的具体实现其实是哈希表，只是它不是将文档 ID 或者题目作为 key，而是反过来，通过将内容或者属性作为 key 来存储对应的文档列表，使得我们能在 O(1) 的时间代价内完成查询。

尽管原理并不复杂，但是倒排索引是许多检索引擎的核心。比如说，数据库的全文索引功能、搜索引擎的索引、广告引擎和推荐引擎，都使用了倒排索引技术来实现检索功能。

# 索引的维护

# 创建索引

  • 数据压缩：一个是尽可能地将数据加载到内存中，因为内存的检索效率大大高于磁盘。那为了将数据更多地加载到内存中，索引压缩是一个重要的研究方向。
  • 分支处理：另一个是将大数据集合拆成多个小数据集合来处理。这其实就是分布式系统的核心思想。

# 更新索引

（1）Double Buffer（双缓冲）机制

就是在内存中同时保存两份一样的索引，一个是索引 A，一个是索引 B。两个索引保持一个读、一个写，并且来回切换，最终完成高性能的索引更新。

优点：简单高效

缺点：达到一定数据量级后，会带来翻倍的内存开销，甚至有些索引存储在磁盘上的情况下，更是无法使用此机制。

（2）全量索引和增量索引

将新接收到的数据单独建立一个可以存在内存中的倒排索引，也就是增量索引。当查询发生的时候，我们会同时查询全量索引和增量索引，将合并的结果作为总的结果输出。

因为增量索引相对全量索引而言会小很多，内存资源消耗在可承受范围，所以我们可以使用 Double Buffer 机制 +对增量索引进行索引更新。这样一来，增量索引就可以做到无锁访问。而全量索引本身就是只读的，也不需要加锁。因此，整个检索过程都可以做到无锁访问，也就提高了系统的检索效率。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#综合#数据结构#索引
上次更新: 2023/06/29, 22:27:04
Nosql技术选型
ShardingSphere 简介

+ ← + ShardingSphere 简介→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/e1b769/index.html b/pages/e1b769/index.html new file mode 100644 index 00000000..951dacf5 --- /dev/null +++ b/pages/e1b769/index.html @@ -0,0 +1,115 @@ + + + + + + Elasticsearch 高亮搜索及显示 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-02-22
目录

Elasticsearch 高亮搜索及显示

# Elasticsearch 高亮搜索及显示

Elasticsearch 的高亮（highlight）可以让您从搜索结果中的一个或多个字段中获取突出显示的摘要，以便向用户显示查询匹配的位置。当您请求突出显示（即高亮）时，响应结果的 highlight 字段中包括高亮的字段和高亮的片段。Elasticsearch 默认会用 <em></em> 标签标记关键字。

# 高亮参数

ES 提供了如下高亮参数：

参数 说明
boundary_chars 包含每个边界字符的字符串。默认为,! ?\ \ n。
boundary_max_scan 扫描边界字符的距离。默认为 20。
boundary_scanner 指定如何分割突出显示的片段，支持 chars、sentence、word 三种方式。
boundary_scanner_locale 用来设置搜索和确定单词边界的本地化设置，此参数使用语言标记的形式（“en-US”, “fr-FR”, “ja-JP”）
encoder 表示代码段应该是 HTML 编码的:默认(无编码)还是 HTML (HTML-转义代码段文本，然后插入高亮标记)
fields 指定检索高亮显示的字段。可以使用通配符来指定字段。例如，可以指定 comment**来获取以 comment*开头的所有文本和关键字字段的高亮显示。
force_source 根据源高亮显示。默认值为 false。
fragmenter 指定文本应如何在突出显示片段中拆分:支持参数 simple 或者 span。
fragment_offset 控制要开始突出显示的空白。仅在使用 fvh highlighter 时有效。
fragment_size 字符中突出显示的片段的大小。默认为 100。
highlight_query 突出显示搜索查询之外的其他查询的匹配项。这在使用重打分查询时特别有用，因为默认情况下高亮显示不会考虑这些问题。
matched_fields 组合多个匹配结果以突出显示单个字段，对于使用不同方式分析同一字符串的多字段。所有的 matched_fields 必须将 term_vector 设置为 with_positions_offsets，但是只有将匹配项组合到的字段才会被加载，因此只有将 store 设置为 yes 才能使该字段受益。只适用于 fvh highlighter。
no_match_size 如果没有要突出显示的匹配片段，则希望从字段开头返回的文本量。默认为 0(不返回任何内容)。
number_of_fragments 返回的片段的最大数量。如果片段的数量设置为 0，则不会返回任何片段。相反，突出显示并返回整个字段内容。当需要突出显示短文本(如标题或地址)，但不需要分段时，使用此配置非常方便。如果 number_of_fragments 为 0，则忽略 fragment_size。默认为 5。
order 设置为 score 时，按分数对突出显示的片段进行排序。默认情况下，片段将按照它们在字段中出现的顺序输出(order:none)。将此选项设置为 score 将首先输出最相关的片段。每个高亮应用自己的逻辑来计算相关性得分。
phrase_limit 控制文档中所考虑的匹配短语的数量。防止 fvh highlighter 分析太多的短语和消耗太多的内存。提高限制会增加查询时间并消耗更多内存。默认为 256。
pre_tags 与 post_tags 一起使用，定义用于突出显示文本的 HTML 标记。默认情况下，突出显示的文本被包装在和标记中。指定为字符串数组。
post_tags 与 pre_tags 一起使用，定义用于突出显示文本的 HTML 标记。默认情况下，突出显示的文本被包装在和标记中。指定为字符串数组。
require_field_match 默认情况下，只突出显示包含查询匹配的字段。将 require_field_match 设置为 false 以突出显示所有字段。默认值为 true。
tags_schema 设置为使用内置标记模式的样式。
type 使用的高亮模式，可选项为**unified、plain或fvh**。默认为 unified。

# 自定义高亮片段

如果我们想使用自定义标签，在高亮属性中给需要高亮的字段加上 pre_tags 和 post_tags 即可。例如，搜索 title 字段中包含关键词 javascript 的书籍并使用自定义 HTML 标签高亮关键词，查询语句如下：

GET /books/_search
+{
+  "query": {
+    "match": { "title": "javascript" }
+  },
+  "highlight": {
+    "fields": {
+      "title": {
+        "pre_tags": ["<strong>"],
+        "post_tags": ["</strong>"]
+      }
+    }
+  }
+}
+

# 多字段高亮

关于搜索高亮，还需要掌握如何设置多字段搜索高亮。比如，搜索 title 字段的时候，我们期望 description 字段中的关键字也可以高亮，这时候就需要把 require_field_match 属性的取值设置为 fasle。require_field_match 的默认值为 true，只会高亮匹配的字段。多字段高亮的查询语句如下：

GET /books/_search
+{
+  "query": {
+    "match": { "title": "javascript" }
+  },
+  "highlight": {
+    "require_field_match": false,
+    "fields": {
+      "title": {},
+      "description": {}
+    }
+  }
+}
+

# 高亮性能分析

Elasticsearch 提供了三种高亮器，分别是默认的 highlighter 高亮器、postings-highlighter 高亮器和 fast-vector-highlighter 高亮器。

默认的 highlighter 是最基本的高亮器。highlighter 高亮器实现高亮功能需要对 _source 中保存的原始文档进行二次分析，其速度在三种高亮器里最慢，优点是不需要额外的存储空间。

postings-highlighter 高亮器实现高亮功能不需要二次分析，但是需要在字段的映射中设置 index_options 参数的取值为 offsets，即保存关键词的偏移量，速度快于默认的 highlighter 高亮器。例如，配置 comment 字段使用 postings-highlighter 高亮器，映射如下：

PUT /example
+{
+  "mappings": {
+    "doc": {
+      "properties": {
+        "comment": {
+          "type": "text",
+          "index_options": "offsets"
+        }
+      }
+    }
+  }
+}
+

fast-vector-highlighter 高亮器实现高亮功能速度最快，但是需要在字段的映射中设置 term_vector 参数的取值为 with_positions_offsets，即保存关键词的位置和偏移信息，占用的存储空间最大，是典型的空间换时间的做法。例如，配置 comment 字段使用 fast-vector-highlighter 高亮器，映射如下：

PUT /example
+{
+  "mappings": {
+    "doc": {
+      "properties": {
+        "comment": {
+          "type": "text",
+          "term_vector": "with_positions_offsets"
+        }
+      }
+    }
+  }
+}
+
+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#高亮
上次更新: 2023/06/29, 22:27:04
Elasticsearch 查询
Elasticsearch 排序

+ ← + Elasticsearch 排序→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/e2648c/index.html b/pages/e2648c/index.html new file mode 100644 index 00000000..25e7b754 --- /dev/null +++ b/pages/e2648c/index.html @@ -0,0 +1,171 @@ + + + + + + 版本管理中间件 Flyway | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2019-08-22
目录

版本管理中间件 Flyway

# 版本管理中间件 Flyway

Flyway 是一个数据迁移工具。

# 简介

# 什么是 Flyway

Flyway 是一个开源的数据库迁移工具。

# 为什么要使用数据迁移

为了说明数据迁移的作用，我们来举一个示例：

（1）假设，有一个叫做 Shiny 的项目，它的架构是一个叫做 Shiny Soft 的 App 连接叫做 Shiny DB 的数据库。

（2）对于大多数项目而言，最简单的持续集成场景如下所示：

img

这意味着，我们不仅仅要处理一份环境中的修改，由此会引入一些版本冲突问题：

在代码侧（即应用软件）的版本问题比较容易解决：

  • 有方便的版本控制工具
  • 有可复用的构建和持续集成
  • 规范的发布和部署过程

那么，数据库层面的版本问题如何解决呢？

目前仍然没有方便的数据库版本工具。许多项目仍使用 sql 脚本来解决版本冲突，甚至是遇到冲突问题时才想起用 sql 语句去解决。

由此，引发一些问题：

  • 机器上的数据库是什么状态？
  • 脚本到底生效没有？
  • 生产环境修复的问题是否也在测试环境修复了？
  • 如何建立一个新的数据库实例？

数据迁移就是用来搞定这些混乱的问题：

  • 通过草稿重建一个数据库。
  • 在任何时候都可以清楚的了解数据库的状态。
  • 以一种明确的方式将数据库从当前版本迁移到一个新版本。

# Flyway 如何工作？

最简单的场景是指定 Flyway 迁移到一个空的数据库。

img

Flyway 会尝试查找它的 schema 历史表，如果数据库是空的，Flyway 就不再查找，而是直接创建数据库。

现再你就有了一个仅包含一张空表的数据库，默认情况下，这张表叫 flyway_schema_history。

img

这张表将被用于追踪数据库的状态。

然后，Flyway 将开始扫描文件系统或应用 classpath 中的 migrations。这些 migrations 可以是 sql 或 java。

这些 migrations 将根据他们的版本号进行排序。

img

任意 migration 应用后，schema 历史表将更新。当元数据和初始状态替换后，可以称之为：迁移到新版本。

Flyway 一旦扫描了文件系统或应用 classpath 下的 migrations，这些 migrations 会检查 schema 历史表。如果它们的版本号低于或等于当前的版本，将被忽略。保留下来的 migrations 是等待的 migrations，有效但没有应用。

img

migrations 将根据版本号排序并按序执行。

img

# 快速上手

Flyway 有 4 种使用方式：

  • 命令行
  • JAVA API
  • Maven
  • Gradle

# 命令行

适用于非 Java 用户，无需构建。

> flyway migrate -url=... -user=... -password=...
+

（1）下载解压

进入官方下载页面 (opens new window)，选择合适版本，下载并解压到本地。

（2）配置 flyway

编辑 /conf/flyway.conf：

flyway.url=jdbc:h2:file:./foobardb
+flyway.user=SA
+flyway.password=
+

（3）创建第一个 migration

在 /sql 目录下创建 V1__Create_person_table.sql 文件，内容如下：

create table PERSON (
+    ID int not null,
+    NAME varchar(100) not null
+);
+

（4）迁移数据库

运行 Flyway 来迁移数据库：

flyway-5.1.4> flyway migrate
+

运行正常的情况下，应该可以看到如下结果：

Database: jdbc:h2:file:./foobardb (H2 1.4)
+Successfully validated 1 migration (execution time 00:00.008s)
+Creating Schema History table: "PUBLIC"."flyway_schema_history"
+Current version of schema "PUBLIC": << Empty Schema >>
+Migrating schema "PUBLIC" to version 1 - Create person table
+Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.033s)
+

（5）添加第二个 migration

在 /sql 目录下创建 V2__Add_people.sql 文件，内容如下：

insert into PERSON (ID, NAME) values (1, 'Axel');
+insert into PERSON (ID, NAME) values (2, 'Mr. Foo');
+insert into PERSON (ID, NAME) values (3, 'Ms. Bar');
+

运行 Flyway

flyway-5.1.4> flyway migrate
+

运行正常的情况下，应该可以看到如下结果：

Database: jdbc:h2:file:./foobardb (H2 1.4)
+Successfully validated 2 migrations (execution time 00:00.018s)
+Current version of schema "PUBLIC": 1
+Migrating schema "PUBLIC" to version 2 - Add people
+Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.016s)
+

# JAVA API

（1）准备

  • Java8+
  • Maven 3.x

（2）添加依赖

在 pom.xml 中添加依赖：

<project ...>
+    ...
+    <dependencies>
+        <dependency>
+            <groupId>org.flywaydb</groupId>
+            <artifactId>flyway-core</artifactId>
+            <version>5.1.4</version>
+        </dependency>
+        <dependency>
+            <groupId>com.h2database</groupId>
+            <artifactId>h2</artifactId>
+            <version>1.3.170</version>
+        </dependency>
+        ...
+    </dependencies>
+    ...
+</project>
+

（3）集成 Flyway

添加 App.java 文件，内容如下：

import org.flywaydb.core.Flyway;
+
+public class App {
+    public static void main(String[] args) {
+        // Create the Flyway instance
+        Flyway flyway = new Flyway();
+
+        // Point it to the database
+        flyway.setDataSource("jdbc:h2:file:./target/foobar", "sa", null);
+
+        // Start the migration
+        flyway.migrate();
+    }
+}
+

（4）创建第一个 migration

添加 src/main/resources/db/migration/V1__Create_person_table.sql 文件，内容如下：

create table PERSON (
+    ID int not null,
+    NAME varchar(100) not null
+);
+

（5）执行程序

执行 App#main：

运行正常的情况下，应该可以看到如下结果：

INFO: Creating schema history table: "PUBLIC"."flyway_schema_history"
+INFO: Current version of schema "PUBLIC": << Empty Schema >>
+INFO: Migrating schema "PUBLIC" to version 1 - Create person table
+INFO: Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.062s).
+

（6）添加第二个 migration

添加 src/main/resources/db/migration/V2__Add_people.sql 文件，内容如下：

insert into PERSON (ID, NAME) values (1, 'Axel');
+insert into PERSON (ID, NAME) values (2, 'Mr. Foo');
+insert into PERSON (ID, NAME) values (3, 'Ms. Bar');
+

运行正常的情况下，应该可以看到如下结果：

INFO: Current version of schema "PUBLIC": 1
+INFO: Migrating schema "PUBLIC" to version 2 - Add people
+INFO: Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.090s).
+

# Maven

与 Java API 方式大体相同，区别在 集成 Flyway 步骤：

Maven 方式使用插件来集成 Flyway：

<project xmlns="...">
+    ...
+    <build>
+        <plugins>
+            <plugin>
+                <groupId>org.flywaydb</groupId>
+                <artifactId>flyway-maven-plugin</artifactId>
+                <version>5.1.4</version>
+                <configuration>
+                    <url>jdbc:h2:file:./target/foobar</url>
+                    <user>sa</user>
+                </configuration>
+                <dependencies>
+                    <dependency>
+                        <groupId>com.h2database</groupId>
+                        <artifactId>h2</artifactId>
+                        <version>1.4.191</version>
+                    </dependency>
+                </dependencies>
+            </plugin>
+        </plugins>
+    </build>
+</project>
+

因为用的是插件，所以执行方式不再是运行 Java 类，而是执行 maven 插件：

> mvn flyway:migrate
+

👉 参考：示例源码 (opens new window)

# Gradle

本人不用 Gradle，略。

# 入门篇

# 概念

# Migrations

在 Flyway 中，对于数据库的任何改变都称之为 Migrations。

Migrations 可以分为 Versioned migrations 和 Repeatable migrations。

Versioned migrations 有 2 种形式：regular 和 undo。

Versioned migrations 和 Repeatable migrations 都可以使用 SQL 或 JAVA 来编写。

# Versioned migrations

由一个版本号（version）、一段描述（description）、一个校验（checksum）组成。版本号必须是惟一的。Versioned migrations 只能按顺序执行一次。

一般用于：

  • 增删改 tables/indexes/foreign keys/enums/UDTs。
  • 引用数据更新
  • 用户数据校正

Regular 示例：

CREATE TABLE car (
+    id INT NOT NULL PRIMARY KEY,
+    license_plate VARCHAR NOT NULL,
+    color VARCHAR NOT NULL
+);
+
+ALTER TABLE owner ADD driver_license_id VARCHAR;
+
+INSERT INTO brand (name) VALUES ('DeLorean');
+
# Undo migrations

注：仅专业版支持

Undo Versioned Migrations 负责撤销 Regular Versioned migrations 的影响。

Undo 示例：

DELETE FROM brand WHERE name='DeLorean';
+
+ALTER TABLE owner DROP driver_license_id;
+
+DROP TABLE car;
+
# Repeatable migrations

由一段描述（description）、一个校验（checksum）组成。Versioned migrations 每次执行后，校验（checksum）会更新。

Repeatable migrations 用于管理可以通过一个文件来维护版本控制的数据库对象。

一般用于：

  • 创建（重建）views/procedures/functions/packages 等。
  • 大量引用数据重新插入

示例：

CREATE OR REPLACE VIEW blue_cars AS
+    SELECT id, license_plate FROM cars WHERE color='blue';
+
# 基于 SQL 的 migrations

migrations 最常用的编写形式就是 SQL。

基于 SQL 的 migrations 一般用于：

  • DDL 变更（针对 TABLES,VIEWS,TRIGGERS,SEQUENCES 等的 CREATE/ALTER/DROP 操作）
  • 简单的引用数据变更（引用数据表中的 CRUD）
  • 简单的大量数据变更（常规数据表中的 CRUD）

命名规则

为了被 Flyway 自动识别，SQL migrations 的文件命名必须遵循规定的模式：

img

  • Prefix - V 代表 versioned migrations (可配置), U 代表 undo migrations (可配置)、 R 代表 repeatable migrations (可配置)
  • Version - 版本号通过.(点)或_(下划线)分隔 (repeatable migrations 不需要)
  • Separator - __ (两个下划线) (可配置)
  • Description - 下划线或空格分隔的单词
  • Suffix - .sql (可配置)
# 基于 JAVA 的 migrations

基于 JAVA 的 migrations 适用于使用 SQL 不容易表达的场景：

  • BLOB 和 CLOB 变更
  • 大量数据的高级变更（重新计算、高级格式变更）

命名规则

为了被 Flyway 自动识别，JAVA migrations 的文件命名必须遵循规定的模式：

img

  • Prefix - V 代表 versioned migrations (可配置), U 代表 undo migrations (可配置)、 R 代表 repeatable migrations (可配置)
  • Version - 版本号通过.(点)或_(下划线)分隔 (repeatable migrations 不需要)
  • Separator - __ (两个下划线) (可配置)
  • Description - 下划线或空格分隔的单词

👉 更多细节请参考：https://flywaydb.org/documentation/migrations

# Callbacks

注：部分 events 仅专业版支持。

尽管 Migrations 可能已经满足绝大部分场景的需要，但是某些情况下需要你一遍又一遍的执行相同的行为。这可能会重新编译存储过程，更新视图以及许多其他类型的开销。

因为以上原因，Flyway 提供了 Callbacks，用于在 Migrations 生命周期中添加钩子。

Callbacks 可以用 SQL 或 JAVA 来实现。

# SQL Callbacks

SQL Callbacks 的命名规则为：event 名 + SQL migration。

如： beforeMigrate.sql, beforeEachMigrate.sql, afterEachMigrate.sql 等。

SQL Callbacks 也可以包含描述（description）。这种情况下，SQL Callbacks 文件名 = event 名 + 分隔符 + 描述 + 后缀。例：beforeRepair__vacuum.sql

当同一个 event 有多个 SQL callbacks，将按照它们描述（description）的顺序执行。

注： Flyway 也支持你配置的 sqlMigrationSuffixes。

# JAVA Callbacks

当 SQL Callbacks 不够方便时，才应考虑 JAVA Callbacks。

JAVA Callbacks 有 3 种形式：

  1. 基于 Java 的 Migrations - 实现 JdbcMigration、SpringJdbcMigration、MigrationInfoProvider、MigrationChecksumProvider、ConfigurationAware、FlywayConfiguration
  2. 基于 Java 的 Callbacks - 实现 org.flywaydb.core.api.callback 接口。
  3. 自定义 Migration resolvers 和 executors - 实现 MigrationResolver、MigrationExecutor、ConfigurationAware、FlywayConfiguration 接口。

👉 更多细节请参考：https://flywaydb.org/documentation/callbacks

# Error Handlers

注：仅专业版支持。

（略）

# Dry Runs

注：仅专业版支持。

（略）

# 命令

Flyway 的功能主要围绕着 7 个基本命令：Migrate (opens new window)、Clean (opens new window)、Info (opens new window)、Validate (opens new window)、Undo (opens new window)、Baseline (opens new window) 和 Repair (opens new window)。

注：各命令的使用方法细节请查阅官方文档。

# 支持的数据库

# 资料

| Github (opens new window) | 官方文档 (opens new window) |

# 🚪 传送门

| 钝悟的博客 (opens new window) | db-tutorial 首页 (opens new window) |

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#中间件#版本管理
上次更新: 2023/06/29, 22:27:04
ShardingSphere Jdbc
关系型数据库面试

+ ← + 关系型数据库面试→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/e33b92/index.html b/pages/e33b92/index.html new file mode 100644 index 00000000..a6ebc07e --- /dev/null +++ b/pages/e33b92/index.html @@ -0,0 +1,352 @@ + + + + + + Mysql 运维 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2019-11-26
目录

Mysql 运维

# Mysql 运维

如果你的公司有 DBA，那么我恭喜你，你可以无视 Mysql 运维。如果你的公司没有 DBA，那你就好好学两手 Mysql 基本运维操作，行走江湖，防身必备。

# 安装部署

# Windows 安装

（1）下载 Mysql 5.7 免安装版

下载地址：https://dev.mysql.com/downloads/mysql/5.7.html#downloads

（2）解压并创建 my.ini 在根目录

my.ini 文件示例：

[mysqld]
+#设置3306端口
+port = 3306
+# 设置mysql的安装目录 这块换成自己解压的路径
+basedir=D:\\Tools\\DB\\mysql\\mysql-5.7.31
+# 允许最大连接数
+max_connections=200
+# 服务端使用的字符集默认为8比特编码的latin1字符集
+character-set-server=utf8
+# 创建新表时将使用的默认存储引擎
+default-storage-engine=INNODB
+
+[client]
+# 设置mysql客户端默认字符集
+default-character-set=utf8
+

（3）执行安装命令

在控制台 CMD 中依次执行以下安装命令

cd D:\\Tools\\DB\\mysql\\mysql-5.7.31
+mysqld --initialize
+mysqld -install
+

说明：

  • mysqld --initialize 会自动初始化创建 data 文件夹并初始化 mysql。
  • mysqld -install 会安装 mysql 服务。

（4）启动服务

在控制台执行 net start mysql 启动服务。

# CentOS 安装

本文仅介绍 rpm 安装方式

# 安装 mysql yum 源

官方下载地址：https://dev.mysql.com/downloads/repo/yum/

（1）下载 yum 源

wget https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm
+

（2）安装 yum repo 文件并更新 yum 缓存

rpm -ivh mysql80-community-release-el7-1.noarch.rpm
+

执行结果：

会在 /etc/yum.repos.d/ 目录下生成两个 repo 文件

$ ls | grep mysql
+mysql-community.repo
+mysql-community-source.repo
+

更新 yum：

yum clean all
+yum makecache
+

（3）查看 rpm 安装状态

$ yum search mysql | grep server
+mysql-community-common.i686 : MySQL database common files for server and client
+mysql-community-common.x86_64 : MySQL database common files for server and
+mysql-community-test.x86_64 : Test suite for the MySQL database server
+                       : administering MySQL servers
+mysql-community-server.x86_64 : A very fast and reliable SQL database server
+

通过 yum 安装 mysql 有几个重要目录：

## 配置文件
+/etc/my.cnf
+## 数据库目录
+/var/lib/mysql/
+## 配置文件
+/usr/share/mysql（mysql.server命令及配置文件）
+## 相关命令
+/usr/bin（mysqladmin mysqldump等命令）
+## 启动脚本
+/usr/lib/systemd/system/mysqld.service （注册为 systemd 服务）
+

（4）安装 mysql 服务器

yum install mysql-community-server
+

# mysql 服务管理

通过 yum 方式安装 mysql 后，本地会有一个名为 mysqld 的 systemd 服务。

其服务管理十分简便：

## 查看状态
+systemctl status mysqld
+## 启用服务
+systemctl enable mysqld
+## 禁用服务
+systemctl disable mysqld
+## 启动服务
+systemctl start mysqld
+## 重启服务
+systemctl restart mysqld
+## 停止服务
+systemctl stop mysqld
+

# 初始化数据库密码

查看一下初始密码

$ grep "password" /var/log/mysqld.log
+2018-09-30T03:13:41.727736Z 5 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: %:lt+srWu4k1
+

执行命令：

mysql -uroot -p<临时密码>
+

输入临时密码，进入 mysql，如果要修改密码，执行以下指令：

ALTER user 'root'@'localhost' IDENTIFIED BY '你的密码';
+

注：密码强度默认为中等，大小写字母、数字、特殊符号，只有修改成功后才能修改配置再设置更简单的密码

# 配置远程访问

CREATE USER 'root'@'%' IDENTIFIED BY '你的密码';
+GRANT ALL ON *.* TO 'root'@'%';
+ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY '你的密码';
+FLUSH PRIVILEGES;
+

# 跳过登录认证

vim /etc/my.cnf
+

在 [mysqld] 下面加上 skip-grant-tables

作用是登录时跳过登录认证，换句话说就是 root 什么密码都可以登录进去。

执行 systemctl restart mysqld，重启 mysql

# 基本运维

# 客户端连接

语法：mysql -h<主机> -P<端口> -u<用户名> -p<密码>

如果没有显式指定密码，会要求输入密码才能访问。

【示例】连接本地 Mysql

$ mysql -h 127.0.0.1 -P 3306 -u root -p
+Enter password:
+Welcome to the MySQL monitor.  Commands end with ; or \g.
+Your MySQL connection id is 13501
+Server version: 8.0.19 MySQL Community Server - GPL
+
+Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
+
+Oracle is a registered trademark of Oracle Corporation and/or its
+affiliates. Other names may be trademarks of their respective
+owners.
+
+Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
+
+mysql>
+

# 查看连接

连接完成后，如果你没有后续的动作，这个连接就处于空闲状态，你可以在 show processlist 命令中看到它。客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。

img

# 创建用户

CREATE USER 'username'@'host' IDENTIFIED BY 'password';
+

说明：

  • username：你将创建的用户名
  • host：指定该用户在哪个主机上可以登陆，如果是本地用户可用 localhost，如果想让该用户可以从任意远程主机登陆，可以使用通配符%
  • password：该用户的登陆密码，密码可以为空，如果为空则该用户可以不需要密码登陆服务器

示例：

CREATE USER 'dog'@'localhost' IDENTIFIED BY '123456';
+CREATE USER 'pig'@'192.168.1.101_' IDENDIFIED BY '123456';
+CREATE USER 'pig'@'%' IDENTIFIED BY '123456';
+CREATE USER 'pig'@'%' IDENTIFIED BY '';
+CREATE USER 'pig'@'%';
+

注意：在 Mysql 8 中，默认密码验证不再是 password。所以在创建用户时，create user 'username'@'%' identified by 'password'; 客户端是无法连接服务的。

所以，需要加上 IDENTIFIED WITH mysql_native_password，例如：CREATE USER 'slave'@'%' IDENTIFIED WITH mysql_native_password BY '123456';

# 查看用户

-- 查看所有用户
+SELECT DISTINCT CONCAT('User: ''', user, '''@''', host, ''';') AS query
+FROM mysql.user;
+

# 授权

命令：

GRANT privileges ON databasename.tablename TO 'username'@'host'
+

说明：

  • privileges：用户的操作权限，如SELECT，INSERT，UPDATE等，如果要授予所的权限则使用ALL
  • databasename：数据库名
  • tablename：表名，如果要授予该用户对所有数据库和表的相应操作权限则可用*表示，如*.*

示例：

GRANT SELECT, INSERT ON test.user TO 'pig'@'%';
+GRANT ALL ON *.* TO 'pig'@'%';
+GRANT ALL ON maindataplus.* TO 'pig'@'%';
+

注意：

用以上命令授权的用户不能给其它用户授权，如果想让该用户可以授权，用以下命令:

-- 为指定用户配置指定权限
+GRANT privileges ON databasename.tablename TO 'username'@'host' WITH GRANT OPTION;
+-- 为 root 用户分配所有权限
+GRANT ALL ON *.* TO 'root'@'%' IDENTIFIED BY '密码' WITH GRANT OPTION;
+

# 撤销授权

命令:

REVOKE privilege ON databasename.tablename FROM 'username'@'host';
+

说明:

privilege, databasename, tablename：同授权部分

例子:

REVOKE SELECT ON *.* FROM 'pig'@'%';
+

注意:

假如你在给用户'pig'@'%'授权的时候是这样的（或类似的）：GRANT SELECT ON test.user TO 'pig'@'%'，则在使用REVOKE SELECT ON *.* FROM 'pig'@'%';命令并不能撤销该用户对 test 数据库中 user 表的SELECT 操作。相反，如果授权使用的是GRANT SELECT ON *.* TO 'pig'@'%';则REVOKE SELECT ON test.user FROM 'pig'@'%';命令也不能撤销该用户对 test 数据库中 user 表的Select权限。

具体信息可以用命令SHOW GRANTS FOR 'pig'@'%'; 查看。

# 查看授权

-- 查看用户权限
+SHOW GRANTS FOR 'root'@'%';
+

# 更改用户密码

SET PASSWORD FOR 'username'@'host' = PASSWORD('newpassword');
+

如果是当前登陆用户用:

SET PASSWORD = PASSWORD("newpassword");
+

示例：

SET PASSWORD FOR 'pig'@'%' = PASSWORD("123456");
+

# 备份与恢复

Mysql 备份数据使用 mysqldump 命令。

mysqldump 将数据库中的数据备份成一个文本文件，表的结构和表中的数据将存储在生成的文本文件中。

备份：

# 备份一个数据库

语法：

mysqldump -h <host> -P<port> -u<username> -p<database> [<table1> <table2> ...] > backup.sql
+
  • host - Mysql Server 的 host
  • port - Mysql Server 的端口
  • username - 数据库用户
  • dbname - 数据库名称
  • table1 和 table2 参数表示需要备份的表的名称，为空则整个数据库备份；
  • BackupName.sql 参数表设计备份文件的名称，文件名前面可以加上一个绝对路径。通常将数据库被分成一个后缀名为 sql 的文件

# 备份多个数据库

mysqldump -u <username> -p --databases <database1> <database2> ... > backup.sql
+

# 备份所有数据库

mysqldump -u <username> -p --all-databases > backup.sql
+

# 恢复一个数据库

Mysql 恢复数据使用 mysql 命令。

语法：

mysql -h <host> -P<port> -u<username> -p<database> < backup.sql
+

# 恢复所有数据库

mysql -u<username> -p --all-databases < backup.sql
+

# 卸载

（1）查看已安装的 mysql

$ rpm -qa | grep -i mysql
+perl-DBD-MySQL-4.023-6.el7.x86_64
+mysql80-community-release-el7-1.noarch
+mysql-community-common-8.0.12-1.el7.x86_64
+mysql-community-client-8.0.12-1.el7.x86_64
+mysql-community-libs-compat-8.0.12-1.el7.x86_64
+mysql-community-libs-8.0.12-1.el7.x86_64
+

（2）卸载 mysql

yum remove mysql-community-server.x86_64
+

# 主从节点部署

假设需要配置一个主从 Mysql 服务器环境

  • master 节点：192.168.8.10
  • slave 节点：192.168.8.11

# 主节点上的操作

（1）修改配置并重启

执行 vi /etc/my.cnf ，添加如下配置：

[mysqld]
+server-id=1
+log_bin=/var/lib/mysql/binlog
+
  • server-id - 服务器 ID 号。在主从架构中，每台机器的 ID 必须唯一。
  • log_bin - 同步的日志路径及文件名，一定注意这个目录要是 mysql 有权限写入的；

修改后，重启 mysql 使配置生效：

systemctl restart mysql
+

（2）创建用于同步的用户

进入 mysql 命令控制台：

$ mysql -u root -p
+Password:
+

执行以下 SQL：

-- a. 创建 slave 用户
+CREATE USER 'slave'@'%' IDENTIFIED WITH mysql_native_password BY '密码';
+-- 为 slave 赋予 REPLICATION SLAVE 权限
+GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%';
+
+-- b. 或者，创建 slave 用户，并指定该用户能在任意主机上登录
+-- 如果有多个从节点，又想让所有从节点都使用统一的用户名、密码认证，可以考虑这种方式
+CREATE USER 'slave'@'%' IDENTIFIED WITH mysql_native_password BY '密码';
+GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%';
+
+-- 刷新授权表信息
+FLUSH PRIVILEGES;
+

注意：在 Mysql 8 中，默认密码验证不再是 password。所以在创建用户时，create user 'username'@'%' identified by 'password'; 客户端是无法连接服务的。所以，需要加上 IDENTIFIED WITH mysql_native_password BY 'password'

补充用户管理 SQL:

-- 查看所有用户
+SELECT DISTINCT CONCAT('User: ''', user, '''@''', host, ''';') AS query
+FROM mysql.user;
+
+-- 查看用户权限
+SHOW GRANTS FOR 'root'@'%';
+
+-- 创建用户
+-- a. 创建 slave 用户，并指定该用户只能在主机 192.168.8.11 上登录
+CREATE USER 'slave'@'192.168.8.11' IDENTIFIED WITH mysql_native_password BY '密码';
+-- 为 slave 赋予 REPLICATION SLAVE 权限
+GRANT REPLICATION SLAVE ON *.* TO 'slave'@'192.168.8.11';
+
+-- 删除用户
+DROP USER 'slave'@'192.168.8.11';
+

（3）加读锁

为了主库与从库的数据保持一致，我们先为 mysql 加入读锁，使其变为只读。

mysql> FLUSH TABLES WITH READ LOCK;
+

（4）查看主节点状态

mysql> show master status;
++------------------+----------+--------------+---------------------------------------------+-------------------+
+| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB                            | Executed_Gtid_Set |
++------------------+----------+--------------+---------------------------------------------+-------------------+
+| mysql-bin.000001 |     4202 |              | mysql,information_schema,performance_schema |                   |
++------------------+----------+--------------+---------------------------------------------+-------------------+
+1 row in set (0.00 sec)
+

注意：需要记录下 File 和 Position，后面会用到。

（5）导出 sql

mysqldump -u root -p --all-databases --master-data > dbdump.sql
+

（6）解除读锁

mysql> UNLOCK TABLES;
+

（7）将 sql 远程传送到从节点上

scp dbdump.sql root@192.168.8.11:/home
+

# 从节点上的操作

（1）修改配置并重启

执行 vi /etc/my.cnf ，添加如下配置：

[mysqld]
+server-id=2
+log_bin=/var/lib/mysql/binlog
+
  • server-id - 服务器 ID 号。在主从架构中，每台机器的 ID 必须唯一。
  • log_bin - 同步的日志路径及文件名，一定注意这个目录要是 mysql 有权限写入的；

修改后，重启 mysql 使配置生效：

systemctl restart mysql
+

（2）导入 sql

mysql -u root -p < /home/dbdump.sql
+

（3）在从节点上建立与主节点的连接

进入 mysql 命令控制台：

$ mysql -u root -p
+Password:
+

执行以下 SQL：

-- 停止从节点服务
+STOP SLAVE;
+
+-- 注意：MASTER_USER 和
+CHANGE MASTER TO
+MASTER_HOST='192.168.8.10',
+MASTER_USER='slave',
+MASTER_PASSWORD='密码',
+MASTER_LOG_FILE='binlog.000001',
+MASTER_LOG_POS=4202;
+
  • MASTER_LOG_FILE 和 MASTER_LOG_POS 参数要分别与 show master status 指令获得的 File 和 Position 属性值对应。
  • MASTER_HOST 是主节点的 HOST。
  • MASTER_USER 和 MASTER_PASSWORD 是在主节点上注册的用户及密码。

（4）启动 slave 进程

mysql> start slave;
+

（5）查看主从同步状态

mysql> show slave status\G;
+

说明：如果以下两项参数均为 YES，说明配置正确。

  • Slave_IO_Running
  • Slave_SQL_Running

（6）将从节点设为只读

mysql> set global read_only=1;
+mysql> set global super_read_only=1;
+mysql> show global variables like "%read_only%";
++-----------------------+-------+
+| Variable_name         | Value |
++-----------------------+-------+
+| innodb_read_only      | OFF   |
+| read_only             | ON    |
+| super_read_only       | ON    |
+| transaction_read_only | OFF   |
++-----------------------+-------+
+

注：设置 slave 服务器为只读，并不影响主从同步。

# 慢查询

查看慢查询是否开启

show variables like '%slow_query_log';
+

可以通过 set global slow_query_log 命令设置慢查询是否开启：ON 表示开启；OFF 表示关闭。

set global slow_query_log='ON';
+

查看慢查询时间阈值

show variables like '%long_query_time%';
+

设置慢查询阈值

set global long_query_time = 3;
+

# 隔离级别

查看隔离级别：

mysql> show variables like 'transaction_isolation';
+ 
++-----------------------+----------------+
+ 
+| Variable_name | Value |
+ 
++-----------------------+----------------+
+ 
+| transaction_isolation | READ-COMMITTED |
+ 
++-----------------------+----------------+
+

# 服务器配置

大部分情况下，默认的基本配置已经足够应付大多数场景，不要轻易修改 Mysql 服务器配置，除非你明确知道修改项是有益的。

尽量不要使用 Mysql 的缓存功能，因为其要求每次请求参数完全相同，才能命中缓存。这种方式实际上并不高效，还会增加额外开销，实际业务场景中一般使用 Redis 等 key-value 存储来解决缓存问题，性能远高于 Mysql 的查询缓存。

# 配置文件路径

配置 Mysql 首先要确定配置文件在哪儿。

不同 Linux 操作系统上，Mysql 配置文件路径可能不同。通常的路径为 /etc/my.cnf 或 /etc/mysql/my.cnf 。

如果不知道配置文件路径，可以尝试以下操作：

# which mysqld
+/usr/sbin/mysqld
+# /usr/sbin/mysqld --verbose --help | grep -A 1 'Default options'
+Default options are read from the following files in the given order:
+/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf
+

# 配置项语法

Mysql 配置项设置都使用小写，单词之间用下划线或横线隔开（二者是等价的）。

建议使用固定的风格，这样检索配置项时较为方便。

# 这两种格式等价
+/usr/sbin/mysqld --auto-increment-offset=5
+/usr/sbin/mysqld --auto_increment_offset=5
+

# 常用配置项说明

这里介绍比较常用的基本配置，更多配置项说明可以参考：Mysql 服务器配置说明

先给出一份常用配置模板，内容如下：

[mysqld]
+# GENERAL
+# -------------------------------------------------------------------------------
+datadir = /var/lib/mysql
+socket  = /var/lib/mysql/mysql.sock
+pid_file = /var/lib/mysql/mysql.pid
+user = mysql
+port = 3306
+default_storage_engine = InnoDB
+default_time_zone = '+8:00'
+character_set_server = utf8mb4
+collation_server = utf8mb4_0900_ai_ci
+
+# LOG
+# -------------------------------------------------------------------------------
+log_error = /var/log/mysql/mysql-error.log
+slow_query_log = 1
+slow_query_log_file = /var/log/mysql/mysql-slow.log
+
+# InnoDB
+# -------------------------------------------------------------------------------
+innodb_buffer_pool_size = <value>
+innodb_log_file_size = <value>
+innodb_file_per_table = 1
+innodb_flush_method = O_DIRECT
+
+# MyIsam
+# -------------------------------------------------------------------------------
+key_buffer_size = <value>
+
+# OTHER
+# -------------------------------------------------------------------------------
+tmp_table_size = 32M
+max_heap_table_size = 32M
+query_cache_type = 0
+query_cache_size = 0
+max_connections = <value>
+thread_cache = <value>
+open_files_limit = 65535
+
+[client]
+socket  = /var/lib/mysql/mysql.sock
+port = 3306
+

  • GENERAL

    • datadir - mysql 数据文件所在目录
    • socket - scoket 文件
    • pid_file - PID 文件
    • user - 启动 mysql 服务进程的用户
    • port - 服务端口号，默认 3306
    • default_storage_engine - mysql 5.1 之后，默认引擎是 InnoDB
    • default_time_zone - 默认时区。中国大部分地区在东八区，即 +8:00
    • character_set_server - 数据库默认字符集
    • collation_server - 数据库字符集对应一些排序等规则，注意要和 character_set_server 对应

  • LOG

    • log_error - 错误日志文件地址
    • slow_query_log - 错误日志文件地址

  • InnoDB

    • innodb_buffer_pool_size - InnoDB 使用一个缓冲池来保存索引和原始数据，不像 MyISAM。这里你设置越大，你在存取表里面数据时所需要的磁盘 I/O 越少。 +
      • 在一个独立使用的数据库服务器上,你可以设置这个变量到服务器物理内存大小的 60%-80%
      • 注意别设置的过大，会导致 system 的 swap 空间被占用，导致操作系统变慢，从而减低 sql 查询的效率
      • 默认值：128M，建议值：物理内存的 60%-80%
    • innodb_log_file_size - 日志文件的大小。默认值：48M，建议值：根据你系统的磁盘空间和日志增长情况调整大小
    • innodb_file_per_table - 说明：mysql5.7 之后默认开启，意思是，每张表一个独立表空间。默认值 1，开启。
    • innodb_flush_method - 说明：控制着 innodb 数据文件及 redo log 的打开、刷写模式，三种模式：fdatasync(默认)，O_DSYNC，O_DIRECT。默认值为空，建议值：使用 SAN 或者 raid，建议用 O_DIRECT，不懂测试的话，默认生产上使用 O_DIRECT +
      • fdatasync：数据文件，buffer pool->os buffer->磁盘；日志文件，buffer pool->os buffer->磁盘；
      • O_DSYNC： 数据文件，buffer pool->os buffer->磁盘；日志文件，buffer pool->磁盘；
      • O_DIRECT： 数据文件，buffer pool->磁盘； 日志文件，buffer pool->os buffer->磁盘；

  • MyIsam

    • key_buffer_size - 指定索引缓冲区的大小，为 MYISAM 数据表开启供线程共享的索引缓存，对 INNODB 引擎无效。相当影响 MyISAM 的性能。 +
      • 不要将其设置大于你可用内存的 30%，因为一部分内存同样被 OS 用来缓冲行数据
      • 甚至在你并不使用 MyISAM 表的情况下，你也需要仍旧设置起 8-64M 内存由于它同样会被内部临时磁盘表使用。
      • 默认值 8M，建议值：对于内存在 4GB 左右的服务器该参数可设置为 256M 或 384M。
      • 注意：该参数值设置的过大反而会是服务器整体效率降低！

  • OTHER

    • tmp_table_size - 内存临时表的最大值，默认 16M，此处设置成 128M
    • max_heap_table_size - 用户创建的内存表的大小，默认 16M，往往和 tmp_table_size 一起设置，限制用户临时表大小。超限的话，MySQL 就会自动地把它转化为基于磁盘的 MyISAM 表，存储在指定的 tmpdir 目录下，增大 IO 压力，建议内存大，增大该数值。
    • query_cache_type - 这个系统变量控制着查询缓存功能的开启和关闭，0 表示关闭，1 表示打开，2 表示只要 select 中明确指定 SQL_CACHE 才缓存。
    • query_cache_size - 默认值 1M，优点是查询缓存可以极大的提高服务器速度，如果你有大量的相同的查询并且很少修改表。缺点：在你表经常变化的情况下或者如果你的查询原文每次都不同，查询缓存也许引起性能下降而不是性能提升。
    • max_connections - 最大连接数，可设最大值 16384，一般考虑根据同时在线人数设置一个比较综合的数字，鉴于该数值增大并不太消耗系统资源，建议直接设 10000。如果在访问时经常出现 Too Many Connections 的错误提示，则需要增大该参数值
    • thread_cache - 当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁。可重用，减小了系统开销。默认值为 9，建议值：两种取值方式， +
      • 方式一，根据物理内存，1G —> 8；2G —> 16； 3G —> 32； >3G —> 64；
      • 方式二，根据 show status like 'threads%'，查看 Threads_connected 值。
    • open_files_limit - MySQL 打开的文件描述符限制，默认最小 1024; +
      • 当 open_files_limit 没有被配置的时候，比较 max_connections*5 和 ulimit -n 的值，哪个大用哪个，
      • 当 open_file_limit 被配置的时候，比较 open_files_limit 和 max_connections*5 的值，哪个大用哪个
      • 注意：仍然可能出现报错信息 Can't create a new thread；此时观察系统 cat /proc/mysql 进程号/limits，观察进程 ulimit 限制情况
      • 过小的话，考虑修改系统配置表，/etc/security/limits.conf 和 /etc/security/limits.d/90-nproc.conf

# 常见问题

# Too many connections

现象

尝试连接 Mysql 时，遇到 Too many connections 错误。

原因

数据库连接线程数超过最大值，访问被拒绝。

解决方案

如果实际连接线程数过大，可以考虑增加服务器节点来分流；如果实际线程数并不算过大，那么可以配置 max_connections 来增加允许的最大连接数。需要注意的是，连接数不宜过大，一般来说，单库每秒有 2000 个并发连接时，就可以考虑扩容了，健康的状态应该维持在每秒 1000 个并发连接左右。

（1）查看最大连接数

mysql> show variables like '%max_connections%';
++------------------------+-------+
+| Variable_name          | Value |
++------------------------+-------+
+| max_connections        | 151   |
+| mysqlx_max_connections | 100   |
++------------------------+-------+
+

（2）查看服务器响应的最大连接数

mysql> show global status like 'Max_used_connections';
++----------------------+-------+
+| Variable_name        | Value |
++----------------------+-------+
+| Max_used_connections | 142   |
++----------------------+-------+
+1 row in set (0.00 sec)
+

（3）临时设置最大连接数

set GLOBAL max_connections=256;
+

注意：当服务器重启时，最大连接数会被重置。

（4）永久设置最大连接数

修改 /etc/my.cnf 配置文件，在 [mysqld] 添加以下配置：

max_connections=256
+

重启 mysql 以生效

（5）修改 Linux 最大文件数限制

设置了最大连接数，如果还是没有生效，考虑检查一下 Linux 最大文件数

Mysql 最大连接数会受到最大文件数限制，vim /etc/security/limits.conf，添加 mysql 用户配置

mysql hard nofile 65535
+mysql soft nofile 65535
+

（6）检查 LimitNOFILE

如果是使用 rpm 方式安装 mysql，检查 mysqld.service 文件中的 LimitNOFILE 是否配置的太小。

# 时区（time_zone）偏差

现象

数据库中存储的 Timestamp 字段值比真实值少了 13 个小时。

原因

  • 当 JDBC 与 MySQL 开始建立连接时，会获取服务器参数。
  • 当 MySQL 的 time_zone 值为 SYSTEM 时，会取 system_time_zone 值作为协调时区，若得到的是 CST 那么 Java 会误以为这是 CST -0500 ，因此会给出错误的时区信息（国内一般是CST +0800，即东八区）。

查看时区方法：

通过 show variables like '%time_zone%'; 命令查看 Mysql 时区配置：

mysql> show variables like '%time_zone%';
++------------------+--------+
+| Variable_name    | Value  |
++------------------+--------+
+| system_time_zone | CST    |
+| time_zone        | SYSTEM |
++------------------+--------+
+

解决方案

方案一

mysql> set global time_zone = '+08:00';
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> set time_zone = '+08:00';
+Query OK, 0 rows affected (0.00 sec)
+

方案二

修改 my.cnf 文件，在 [mysqld] 节下增加 default-time-zone='+08:00' ，然后重启。

# 数据表损坏如何修复

使用 myisamchk 来修复，具体步骤：

  1. 修复前将 mysql 服务停止。
  2. 打开命令行方式，然后进入到 mysql 的 bin 目录。
  3. 执行 myisamchk –recover 数据库所在路 /*.MYI

使用 repair table 或者 OPTIMIZE table 命令来修复，REPAIR TABLE table_name 修复表 OPTIMIZE TABLE table_name 优化表 REPAIR TABLE 用于修复被破坏的表。 OPTIMIZE TABLE 用于回收闲置的数据库空间，当表上的数据行被删除时，所占据的磁盘空间并没有立即被回收，使用了 OPTIMIZE TABLE 命令后这些空间将被回收，并且对磁盘上的数据行进行重排（注意：是磁盘上，而非数据库）

# 数据结构

问题现象：ERROR 1071: Specified key was too long; max key length is 767 bytes

问题原因：Mysql 默认情况下单个列的索引不能超过 767 位（不同版本可能存在差异） 。

解决方法：优化索引结构，索引字段不宜过长。

# 脚本

这里推荐我写的几个一键运维脚本，非常方便，欢迎使用：

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#Mysql#运维
上次更新: 2023/06/29, 22:27:04
Mysql 性能优化
Mysql 配置

+ ← + Mysql 配置→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/e438a7/index.html b/pages/e438a7/index.html new file mode 100644 index 00000000..45c63f30 --- /dev/null +++ b/pages/e438a7/index.html @@ -0,0 +1,62 @@ + + + + + + SQL Cheat Sheet | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-07-16
目录

SQL Cheat Sheet

# SQL Cheat Sheet

# 查找数据的查询

# SELECT: 用于从数据库中选择数据

  • SELECT * FROM table_name;

# DISTINCT: 用于过滤掉重复的值并返回指定列的行

  • SELECT DISTINCT column_name;

# WHERE: 用于过滤记录/行

  • SELECT column1, column2 FROM table_name WHERE condition;
  • SELECT * FROM table_name WHERE condition1 AND condition2;
  • SELECT * FROM table_name WHERE condition1 OR condition2;
  • SELECT * FROM table_name WHERE NOT condition;
  • SELECT * FROM table_name WHERE condition1 AND (condition2 OR condition3);
  • SELECT * FROM table_name WHERE EXISTS (SELECT column_name FROM table_name WHERE condition);

# ORDER BY: 用于结果集的排序，升序（ASC）或者降序（DESC）

  • SELECT * FROM table_name ORDER BY column;
  • SELECT * FROM table_name ORDER BY column DESC;
  • SELECT * FROM table_name ORDER BY column1 ASC, column2 DESC;

# SELECT TOP: 用于指定从表顶部返回的记录数

  • SELECT TOP number columns_names FROM table_name WHERE condition;
  • SELECT TOP percent columns_names FROM table_name WHERE condition;
  • 并非所有数据库系统都支持SELECT TOP。 MySQL 中是LIMIT子句
  • SELECT column_names FROM table_name LIMIT offset, count;

# LIKE: 用于搜索列中的特定模式，WHERE 子句中使用的运算符

  • % (percent sign) 是一个表示零个，一个或多个字符的通配符
  • _ (underscore) 是一个表示单个字符通配符
  • SELECT column_names FROM table_name WHERE column_name LIKE pattern;
  • LIKE ‘a%’ （查找任何以“a”开头的值）
  • LIKE ‘%a’ （查找任何以“a”结尾的值）
  • LIKE ‘%or%’ （查找任何包含“or”的值）
  • LIKE ‘_r%’ （查找任何第二位是“r”的值）
  • LIKE ‘a*%*%’ （查找任何以“a”开头且长度至少为 3 的值）
  • LIKE ‘[a-c]%’（查找任何以“a”或“b”或“c”开头的值）

# IN: 用于在 WHERE 子句中指定多个值的运算符

  • 本质上，IN 运算符是多个 OR 条件的简写
  • SELECT column_names FROM table_name WHERE column_name IN (value1, value2, …);
  • SELECT column_names FROM table_name WHERE column_name IN (SELECT STATEMENT);

# BETWEEN: 用于过滤给定范围的值的运算符

  • SELECT column_names FROM table_name WHERE column_name BETWEEN value1 AND value2;
  • SELECT * FROM Products WHERE (column_name BETWEEN value1 AND value2) AND NOT column_name2 IN (value3, value4);
  • SELECT * FROM Products WHERE column_name BETWEEN #01/07/1999# AND #03/12/1999#;

# NULL: 代表一个字段没有值

  • SELECT * FROM table_name WHERE column_name IS NULL;
  • SELECT * FROM table_name WHERE column_name IS NOT NULL;

# AS: 用于给表或者列分配别名

  • SELECT column_name AS alias_name FROM table_name;
  • SELECT column_name FROM table_name AS alias_name;
  • SELECT column_name AS alias_name1, column_name2 AS alias_name2;
  • SELECT column_name1, column_name2 + ‘, ‘ + column_name3 AS alias_name;

# UNION: 用于组合两个或者多个 SELECT 语句的结果集的运算符

  • 每个 SELECT 语句必须拥有相同的列数
  • 列必须拥有相似的数据类型
  • 每个 SELECT 语句中的列也必须具有相同的顺序
  • SELECT columns_names FROM table1 UNION SELECT column_name FROM table2;
  • UNION 仅允许选择不同的值, UNION ALL 允许重复

# ANY|ALL: 用于检查 WHERE 或 HAVING 子句中使用的子查询条件的运算符

  • ANY 如果任何子查询值满足条件，则返回 true。
  • ALL 如果所有子查询值都满足条件，则返回 true。
  • SELECT columns_names FROM table1 WHERE column_name operator (ANY|ALL) (SELECT column_name FROM table_name WHERE condition);

# GROUP BY: 通常与聚合函数（COUNT，MAX，MIN，SUM，AVG）一起使用，用于将结果集分组为一列或多列

  • SELECT column_name1, COUNT(column_name2) FROM table_name WHERE condition GROUP BY column_name1 ORDER BY COUNT(column_name2) DESC;

# HAVING: HAVING 子句指定 SELECT 语句应仅返回聚合值满足指定条件的行。它被添加到 SQL 语言中，因为 WHERE 关键字不能与聚合函数一起使用。

  • SELECT COUNT(column_name1), column_name2 FROM table GROUP BY column_name2 HAVING COUNT(column_name1) > 5;

# 修改数据的查询

# INSERT INTO: 用于在表中插入新记录/行

  • INSERT INTO table_name (column1, column2) VALUES (value1, value2);
  • INSERT INTO table_name VALUES (value1, value2 …);

# UPDATE: 用于修改表中的现有记录/行

  • UPDATE table_name SET column1 = value1, column2 = value2 WHERE condition;
  • UPDATE table_name SET column_name = value;

# DELETE: 用于删除表中的现有记录/行

  • DELETE FROM table_name WHERE condition;
  • DELETE * FROM table_name;

# 聚合查询

# COUNT: 返回出现次数

  • SELECT COUNT (DISTINCT column_name);

# MIN() and MAX(): 返回所选列的最小/最大值

  • SELECT MIN (column_names) FROM table_name WHERE condition;
  • SELECT MAX (column_names) FROM table_name WHERE condition;

# AVG(): 返回数字列的平均值

  • SELECT AVG (column_name) FROM table_name WHERE condition;

# SUM(): 返回数值列的总和

  • SELECT SUM (column_name) FROM table_name WHERE condition;

# 连接查询

# INNER JOIN: 内连接，返回在两张表中具有匹配值的记录

  • SELECT column_names FROM table1 INNER JOIN table2 ON table1.column_name=table2.column_name;
  • SELECT table1.column_name1, table2.column_name2, table3.column_name3 FROM ((table1 INNER JOIN table2 ON relationship) INNER JOIN table3 ON relationship);

# LEFT (OUTER) JOIN: 左外连接，返回左表（table1）中的所有记录，以及右表中的匹配记录（table2）

  • SELECT column_names FROM table1 LEFT JOIN table2 ON table1.column_name=table2.column_name;

# RIGHT (OUTER) JOIN: 右外连接，返回右表（table2）中的所有记录，以及左表（table1）中匹配的记录

  • SELECT column_names FROM table1 RIGHT JOIN table2 ON table1.column_name=table2.column_name;

# FULL (OUTER) JOIN: 全外连接，全连接是左右外连接的并集. 连接表包含被连接的表的所有记录, 如果缺少匹配的记录, 以 NULL 填充。

  • SELECT column_names FROM table1 FULL OUTER JOIN table2 ON table1.column_name=table2.column_name;

# Self JOIN: 自连接，表自身连接

  • SELECT column_names FROM table1 T1, table1 T2 WHERE condition;

# 视图查询

# CREATE: 创建视图

  • CREATE VIEW view_name AS SELECT column1, column2 FROM table_name WHERE condition;

# SELECT: 检索视图

  • SELECT * FROM view_name;

# DROP: 删除视图

  • DROP VIEW view_name;

# 修改表的查询

# ADD: 添加字段

  • ALTER TABLE table_name ADD column_name column_definition;

# MODIFY: 修改字段数据类型

  • ALTER TABLE table_name MODIFY column_name column_type;

# DROP: 删除字段

  • ALTER TABLE table_name DROP COLUMN column_name;
+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#SQL
上次更新: 2023/06/29, 22:27:04
扩展 SQL
Mysql 应用指南

+ ← + Mysql 应用指南→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/ed757c/index.html b/pages/ed757c/index.html new file mode 100644 index 00000000..a698e1e7 --- /dev/null +++ b/pages/ed757c/index.html @@ -0,0 +1,727 @@ + + + + + + Redis 数据类型和应用 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-24
目录

Redis 数据类型和应用

# Redis 数据类型和应用

Redis 提供了多种数据类型，每种数据类型有丰富的命令支持。

使用 Redis ，不仅要了解其数据类型的特性，还需要根据业务场景，灵活的、高效的使用其数据类型来建模。

# 一、Redis 基本数据类型

Redis 数据类型

数据类型 可以存储的值 操作
STRING 字符串、整数或者浮点数 对整个字符串或者字符串的其中一部分执行操作
对整数和浮点数执行自增或者自减操作
LIST 列表 从两端压入或者弹出元素
读取单个或者多个元素
进行修剪，只保留一个范围内的元素
SET 无序集合 添加、获取、移除单个元素
检查一个元素是否存在于集合中
计算交集、并集、差集
从集合里面随机获取元素
HASH 包含键值对的无序散列表 添加、获取、移除单个键值对
获取所有键值对
检查某个键是否存在
ZSET 有序集合 添加、获取、删除元素
根据分值范围或者成员来获取元素
计算一个键的排名

What Redis data structures look like (opens new window)

# STRING

+**适用场景：缓存、计数器、共享 Session** +

命令：

命令 行为
GET 获取存储在给定键中的值。
SET 设置存储在给定键中的值。
DEL 删除存储在给定键中的值（这个命令可以用于所有类型）。
INCR 为键 key 储存的数字值加一
DECR 为键 key 储存的数字值减一

更多命令请参考：Redis String 类型命令 (opens new window)

示例：

127.0.0.1:6379> set hello world
+OK
+127.0.0.1:6379> get hello
+"world"
+127.0.0.1:6379> del hello
+(integer) 1
+127.0.0.1:6379> get hello
+(nil)
+

# HASH

+**适用场景：存储结构化数据**，如一个对象：用户信息、产品信息等。 +

命令：

命令 行为
HSET 在散列里面关联起给定的键值对。
HGET 获取指定散列键的值。
HGETALL 获取散列包含的所有键值对。
HDEL 如果给定键存在于散列里面，那么移除这个键。

更多命令请参考：Redis Hash 类型命令 (opens new window)

示例：

127.0.0.1:6379> hset hash-key sub-key1 value1
+(integer) 1
+127.0.0.1:6379> hset hash-key sub-key2 value2
+(integer) 1
+127.0.0.1:6379> hset hash-key sub-key1 value1
+(integer) 0
+127.0.0.1:6379> hset hash-key sub-key3 value2
+(integer) 0
+127.0.0.1:6379> hgetall hash-key
+1) "sub-key1"
+2) "value1"
+3) "sub-key2"
+4) "value2"
+127.0.0.1:6379> hdel hash-key sub-key2
+(integer) 1
+127.0.0.1:6379> hdel hash-key sub-key2
+(integer) 0
+127.0.0.1:6379> hget hash-key sub-key1
+"value1"
+127.0.0.1:6379> hgetall hash-key
+1) "sub-key1"
+2) "value1"
+

# LIST

+**适用场景：用于存储列表型数据**。如：粉丝列表、商品列表等。 +

命令：

命令 行为
LPUSH 将给定值推入列表的右端。
RPUSH 将给定值推入列表的右端。
LPOP 从列表的左端弹出一个值，并返回被弹出的值。
RPOP 从列表的右端弹出一个值，并返回被弹出的值。
LRANGE 获取列表在给定范围上的所有值。
LINDEX 获取列表在给定位置上的单个元素。
LREM 从列表的左端弹出一个值，并返回被弹出的值。
LTRIM 只保留指定区间内的元素，删除其他元素。

更多命令请参考：Redis List 类型命令 (opens new window)

示例：

127.0.0.1:6379> rpush list-key item
+(integer) 1
+127.0.0.1:6379> rpush list-key item2
+(integer) 2
+127.0.0.1:6379> rpush list-key item
+(integer) 3
+127.0.0.1:6379> lrange list-key 0 -1
+1) "item"
+2) "item2"
+3) "item"
+127.0.0.1:6379> lindex list-key 1
+"item2"
+127.0.0.1:6379> lpop list-key
+"item"
+127.0.0.1:6379> lrange list-key 0 -1
+1) "item2"
+2) "item"
+

# SET

+**适用场景：用于存储去重的列表型数据**。 +

命令：

命令 行为
SADD 将给定元素添加到集合。
SMEMBERS 返回集合包含的所有元素。
SISMEMBER 检查给定元素是否存在于集合中。
SREM 如果给定的元素存在于集合中，那么移除这个元素。

更多命令请参考：Redis Set 类型命令 (opens new window)

示例：

127.0.0.1:6379> sadd set-key item
+(integer) 1
+127.0.0.1:6379> sadd set-key item2
+(integer) 1
+127.0.0.1:6379> sadd set-key item3
+(integer) 1
+127.0.0.1:6379> sadd set-key item
+(integer) 0
+127.0.0.1:6379> smembers set-key
+1) "item"
+2) "item2"
+3) "item3"
+127.0.0.1:6379> sismember set-key item4
+(integer) 0
+127.0.0.1:6379> sismember set-key item
+(integer) 1
+127.0.0.1:6379> srem set-key item2
+(integer) 1
+127.0.0.1:6379> srem set-key item2
+(integer) 0
+127.0.0.1:6379> smembers set-key
+1) "item"
+2) "item3"
+

# ZSET

适用场景：由于可以设置 score，且不重复。适合用于存储各种排行数据，如：按评分排序的有序商品集合、按时间排序的有序文章集合。

命令：

命令 行为
ZADD 将一个带有给定分值的成员添加到有序集合里面。
ZRANGE 根据元素在有序排列中所处的位置，从有序集合里面获取多个元素。
ZRANGEBYSCORE 获取有序集合在给定分值范围内的所有元素。
ZREM 如果给定成员存在于有序集合，那么移除这个成员。

更多命令请参考：Redis ZSet 类型命令 (opens new window)

示例：

127.0.0.1:6379> zadd zset-key 728 member1
+(integer) 1
+127.0.0.1:6379> zadd zset-key 982 member0
+(integer) 1
+127.0.0.1:6379> zadd zset-key 982 member0
+(integer) 0
+
+127.0.0.1:6379> zrange zset-key 0 -1 withscores
+1) "member1"
+2) "728"
+3) "member0"
+4) "982"
+
+127.0.0.1:6379> zrangebyscore zset-key 0 800 withscores
+1) "member1"
+2) "728"
+
+127.0.0.1:6379> zrem zset-key member1
+(integer) 1
+127.0.0.1:6379> zrem zset-key member1
+(integer) 0
+127.0.0.1:6379> zrange zset-key 0 -1 withscores
+1) "member0"
+2) "982"
+

# 通用命令

# 排序

Redis 的 SORT 命令可以对 LIST、SET、ZSET 进行排序。

命令 描述
SORT SORT source-key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern ...]] [ASC | DESC] [ALPHA] [STORE dest-key]—根据给定选项，对输入 LIST、SET、ZSET 进行排序，然后返回或存储排序的结果。

示例：

127.0.0.1:6379[15]> RPUSH 'sort-input' 23 15 110 7
+(integer) 4
+127.0.0.1:6379[15]> SORT 'sort-input'
+1) "7"
+2) "15"
+3) "23"
+4) "110"
+127.0.0.1:6379[15]> SORT 'sort-input' alpha
+1) "110"
+2) "15"
+3) "23"
+4) "7"
+127.0.0.1:6379[15]> HSET 'd-7' 'field' 5
+(integer) 1
+127.0.0.1:6379[15]> HSET 'd-15' 'field' 1
+(integer) 1
+127.0.0.1:6379[15]> HSET 'd-23' 'field' 9
+(integer) 1
+127.0.0.1:6379[15]> HSET 'd-110' 'field' 3
+(integer) 1
+127.0.0.1:6379[15]> SORT 'sort-input' by 'd-*->field'
+1) "15"
+2) "110"
+3) "7"
+4) "23"
+127.0.0.1:6379[15]> SORT 'sort-input' by 'd-*->field' get 'd-*->field'
+1) "1"
+2) "3"
+3) "5"
+4) "9"
+

# 键的过期时间

Redis 的 EXPIRE 命令可以指定一个键的过期时间，当达到过期时间后，Redis 会自动删除该键。

命令 描述
PERSIST PERSIST key-name—移除键的过期时间
TTL TTL key-name—查看给定键距离过期还有多少秒
EXPIRE EXPIRE key-name seconds—让给定键在指定的秒数之后过期
EXPIREAT EXPIREAT key-name timestamp—将给定键的过期时间设置为给定的 UNIX 时间戳
PTTL PTTL key-name—查看给定键距离过期时间还有多少毫秒（这个命令在 Redis 2.6 或以上版本可用）
PEXPIRE PEXPIRE key-name milliseconds—让给定键在指定的毫秒数之后过期（这个命令在 Redis 2.6 或以上版本可用）
PEXPIREAT PEXPIREAT key-name timestamp-milliseconds—将一个毫秒级精度的 UNIX 时间戳设置为给定键的过期时间（这个命令在 Redis 2.6 或以上版本可用）

示例：

127.0.0.1:6379[15]> SET key value
+OK
+127.0.0.1:6379[15]> GET key
+"value"
+127.0.0.1:6379[15]> EXPIRE key 2
+(integer) 1
+127.0.0.1:6379[15]> GET key
+(nil)
+

# 二、Redis 高级数据类型

# BitMap

BitMap 即位图。BitMap 不是一个真实的数据结构。而是 STRING 类型上的一组面向 bit 操作的集合。由于 STRING 是二进制安全的 blob，并且它们的最大长度是 512m，所以 BitMap 能最大设置 $$2^{32}$$ 个不同的 bit。

Bitmaps 的最大优点就是存储信息时可以节省大量的空间。例如在一个系统中，不同的用户被一个增长的用户 ID 表示。40 亿（$$2^{32}$$ = $$410241024*1024$$ ≈ 40 亿）用户只需要 512M 内存就能记住某种信息，例如用户是否登录过。

# BitMap 命令

# BitMap 示例

# 对不存在的 key 或者不存在的 offset 进行 GETBIT， 返回 0
+
+redis> EXISTS bit
+(integer) 0
+
+redis> GETBIT bit 10086
+(integer) 0
+
+
+# 对已存在的 offset 进行 GETBIT
+
+redis> SETBIT bit 10086 1
+(integer) 0
+
+redis> GETBIT bit 10086
+(integer) 1
+
+redis> BITCOUNT bit
+(integer) 1
+

# BitMap 应用

Bitmap 对于一些特定类型的计算非常有效。例如：使用 bitmap 实现用户上线次数统计。

假设现在我们希望记录自己网站上的用户的上线频率，比如说，计算用户 A 上线了多少天，用户 B 上线了多少天，诸如此类，以此作为数据，从而决定让哪些用户参加 beta 测试等活动 —— 这个模式可以使用 SETBIT key offset value (opens new window) 和 [BITCOUNT key start] [end] (opens new window) 来实现。

比如说，每当用户在某一天上线的时候，我们就使用 SETBIT key offset value (opens new window) ，以用户名作为 key，将那天所代表的网站的上线日作为 offset 参数，并将这个 offset 上的为设置为 1 。

更详细的实现可以参考：

一看就懂系列之 详解 redis 的 bitmap 在亿级项目中的应用 (opens new window)

Fast, easy, realtime metrics using Redis bitmaps (opens new window)

# HyperLogLog

HyperLogLog 是用于计算唯一事物的概率数据结构（从技术上讲，这被称为估计集合的基数）。如果统计唯一项，项目越多，需要的内存就越多。因为需要记住过去已经看过的项，从而避免多次统计这些项。

# HyperLogLog 命令

  • PFADD (opens new window) - 将任意数量的元素添加到指定的 HyperLogLog 里面。
  • PFCOUNT (opens new window) - 返回 HyperLogLog 包含的唯一元素的近似数量。
  • PFMERGE (opens new window) - 将多个 HyperLogLog 合并（merge）为一个 HyperLogLog ， 合并后的 HyperLogLog 的基数接近于所有输入 HyperLogLog 的可见集合（observed set）的并集。合并得出的 HyperLogLog 会被储存在 destkey 键里面， 如果该键并不存在， 那么命令在执行之前， 会先为该键创建一个空的 HyperLogLog 。

示例：

redis> PFADD  databases  "Redis"  "MongoDB"  "MySQL"
+(integer) 1
+
+redis> PFCOUNT  databases
+(integer) 3
+
+redis> PFADD  databases  "Redis"    # Redis 已经存在，不必对估计数量进行更新
+(integer) 0
+
+redis> PFCOUNT  databases    # 元素估计数量没有变化
+(integer) 3
+
+redis> PFADD  databases  "PostgreSQL"    # 添加一个不存在的元素
+(integer) 1
+
+redis> PFCOUNT  databases    # 估计数量增一
+4
+

# GEO

这个功能可以将用户给定的地理位置（经度和纬度）信息储存起来，并对这些信息进行操作。

# GEO 命令

# 三、Redis 数据类型应用

# 案例-最受欢迎文章

选出最受欢迎文章，需要支持对文章进行评分。

# 对文章进行投票

（1）使用 HASH 存储文章

使用 HASH 类型存储文章信息。其中：key 是文章 ID；field 是文章的属性 key；value 是属性对应值。

img

操作：

  • 存储文章信息 - 使用 HSET 或 HMGET 命令
  • 查询文章信息 - 使用 HGETALL 命令
  • 添加投票 - 使用 HINCRBY 命令

（2）使用 ZSET 针对不同维度集合排序

使用 ZSET 类型分别存储按照时间排序和按照评分排序的文章 ID 集合。

img

操作：

  • 添加记录 - 使用 ZADD 命令
  • 添加分数 - 使用 ZINCRBY 命令
  • 取出多篇文章 - 使用 ZREVRANGE 命令

（3）为了防止重复投票，使用 SET 类型记录每篇文章 ID 对应的投票集合。

img

操作：

  • 添加投票者 - 使用 SADD 命令
  • 设置有效期 - 使用 EXPIRE 命令

（4）假设 user:115423 给 article:100408 投票，分别需要高更新评分排序集合以及投票集合。

img

当需要对一篇文章投票时，程序需要用 ZSCORE 命令检查记录文章发布时间的有序集合，判断文章的发布时间是否超过投票有效期（比如：一星期）。

    public void articleVote(Jedis conn, String user, String article) {
+        // 计算文章的投票截止时间。
+        long cutoff = (System.currentTimeMillis() / 1000) - ONE_WEEK_IN_SECONDS;
+
+        // 检查是否还可以对文章进行投票
+        // （虽然使用散列也可以获取文章的发布时间，
+        // 但有序集合返回的文章发布时间为浮点数，
+        // 可以不进行转换直接使用）。
+        if (conn.zscore("time:", article) < cutoff) {
+            return;
+        }
+
+        // 从article:id标识符（identifier）里面取出文章的ID。
+        String articleId = article.substring(article.indexOf(':') + 1);
+
+        // 如果用户是第一次为这篇文章投票，那么增加这篇文章的投票数量和评分。
+        if (conn.sadd("voted:" + articleId, user) == 1) {
+            conn.zincrby("score:", VOTE_SCORE, article);
+            conn.hincrBy(article, "votes", 1);
+        }
+    }
+

# 发布并获取文章

发布文章：

  • 添加文章 - 使用 INCR 命令计算新的文章 ID，填充文章信息，然后用 HSET 命令或 HMSET 命令写入到 HASH 结构中。
  • 将文章作者 ID 添加到投票名单 - 使用 SADD 命令添加到代表投票名单的 SET 结构中。
  • 设置投票有效期 - 使用 EXPIRE 命令设置投票有效期。
    public String postArticle(Jedis conn, String user, String title, String link) {
+        // 生成一个新的文章ID。
+        String articleId = String.valueOf(conn.incr("article:"));
+
+        String voted = "voted:" + articleId;
+        // 将发布文章的用户添加到文章的已投票用户名单里面，
+        conn.sadd(voted, user);
+        // 然后将这个名单的过期时间设置为一周（第3章将对过期时间作更详细的介绍）。
+        conn.expire(voted, ONE_WEEK_IN_SECONDS);
+
+        long now = System.currentTimeMillis() / 1000;
+        String article = "article:" + articleId;
+        // 将文章信息存储到一个散列里面。
+        HashMap<String, String> articleData = new HashMap<String, String>();
+        articleData.put("title", title);
+        articleData.put("link", link);
+        articleData.put("user", user);
+        articleData.put("now", String.valueOf(now));
+        articleData.put("votes", "1");
+        conn.hmset(article, articleData);
+
+        // 将文章添加到根据发布时间排序的有序集合和根据评分排序的有序集合里面。
+        conn.zadd("score:", now + VOTE_SCORE, article);
+        conn.zadd("time:", now, article);
+
+        return articleId;
+    }
+

分页查询最受欢迎文章：

使用 ZINTERSTORE 命令根据页码、每页记录数、排序号，根据评分值从大到小分页查出文章 ID 列表。

    public List<Map<String, String>> getArticles(Jedis conn, int page, String order) {
+        // 设置获取文章的起始索引和结束索引。
+        int start = (page - 1) * ARTICLES_PER_PAGE;
+        int end = start + ARTICLES_PER_PAGE - 1;
+
+        // 获取多个文章ID。
+        Set<String> ids = conn.zrevrange(order, start, end);
+        List<Map<String, String>> articles = new ArrayList<>();
+        // 根据文章ID获取文章的详细信息。
+        for (String id : ids) {
+            Map<String, String> articleData = conn.hgetAll(id);
+            articleData.put("id", id);
+            articles.add(articleData);
+        }
+
+        return articles;
+    }
+

# 对文章进行分组

如果文章需要分组，功能需要分为两块：

  • 记录文章属于哪个群组
  • 负责取出群组里的文章

将文章添加、删除群组：

    public void addRemoveGroups(Jedis conn, String articleId, String[] toAdd, String[] toRemove) {
+        // 构建存储文章信息的键名。
+        String article = "article:" + articleId;
+        // 将文章添加到它所属的群组里面。
+        for (String group : toAdd) {
+            conn.sadd("group:" + group, article);
+        }
+        // 从群组里面移除文章。
+        for (String group : toRemove) {
+            conn.srem("group:" + group, article);
+        }
+    }
+

取出群组里的文章：

img

  • 通过对存储群组文章的集合和存储文章评分的有序集合执行 ZINTERSTORE 命令，可以得到按照文章评分排序的群组文章。
  • 通过对存储群组文章的集合和存储文章发布时间的有序集合执行 ZINTERSTORE 命令，可以得到按照文章发布时间排序的群组文章。
    public List<Map<String, String>> getGroupArticles(Jedis conn, String group, int page, String order) {
+        // 为每个群组的每种排列顺序都创建一个键。
+        String key = order + group;
+        // 检查是否有已缓存的排序结果，如果没有的话就现在进行排序。
+        if (!conn.exists(key)) {
+            // 根据评分或者发布时间，对群组文章进行排序。
+            ZParams params = new ZParams().aggregate(ZParams.Aggregate.MAX);
+            conn.zinterstore(key, params, "group:" + group, order);
+            // 让Redis在60秒钟之后自动删除这个有序集合。
+            conn.expire(key, 60);
+        }
+        // 调用之前定义的getArticles函数来进行分页并获取文章数据。
+        return getArticles(conn, page, key);
+    }
+

# 案例-管理令牌

网站一般会以 Cookie、Session、令牌这类信息存储用户身份信息。

可以将 Cookie/Session/令牌 和用户的映射关系存储在 HASH 结构。

下面以令牌来举例。

# 查询令牌

    public String checkToken(Jedis conn, String token) {
+        // 尝试获取并返回令牌对应的用户。
+        return conn.hget("login:", token);
+    }
+

# 更新令牌

  • 用户每次访问页面，可以记录下令牌和当前时间戳的映射关系，存入一个 ZSET 结构中，以便分析用户是否活跃，继而可以周期性清理最老的令牌，统计当前在线用户数等行为。
  • 用户如果正在浏览商品，可以记录到用户最近浏览过的商品有序集合中（集合可以限定数量，超过数量进行裁剪），存入到一个 ZSET 结构中，以便分析用户最近可能感兴趣的商品，以便推荐商品。
    public void updateToken(Jedis conn, String token, String user, String item) {
+        // 获取当前时间戳。
+        long timestamp = System.currentTimeMillis() / 1000;
+        // 维持令牌与已登录用户之间的映射。
+        conn.hset("login:", token, user);
+        // 记录令牌最后一次出现的时间。
+        conn.zadd("recent:", timestamp, token);
+        if (item != null) {
+            // 记录用户浏览过的商品。
+            conn.zadd("viewed:" + token, timestamp, item);
+            // 移除旧的记录，只保留用户最近浏览过的25个商品。
+            conn.zremrangeByRank("viewed:" + token, 0, -26);
+            conn.zincrby("viewed:", -1, item);
+        }
+    }
+

# 清理令牌

上一节提到，更新令牌时，将令牌和当前时间戳的映射关系，存入一个 ZSET 结构中。所以可以通过排序得知哪些令牌最老。如果没有清理操作，更新令牌占用的内存会不断膨胀，直到导致机器宕机。

比如：最多允许存储 1000 万条令牌信息，周期性检查，一旦发现记录数超出 1000 万条，将 ZSET 从新到老排序，将超出 1000 万条的记录清除。

public static class CleanSessionsThread extends Thread {
+
+    private Jedis conn;
+
+    private int limit;
+
+    private volatile boolean quit;
+
+    public CleanSessionsThread(int limit) {
+        this.conn = new Jedis("localhost");
+        this.conn.select(15);
+        this.limit = limit;
+    }
+
+    public void quit() {
+        quit = true;
+    }
+
+    @Override
+    public void run() {
+        while (!quit) {
+            // 找出目前已有令牌的数量。
+            long size = conn.zcard("recent:");
+            // 令牌数量未超过限制，休眠并在之后重新检查。
+            if (size <= limit) {
+                try {
+                    sleep(1000);
+                } catch (InterruptedException ie) {
+                    Thread.currentThread().interrupt();
+                }
+                continue;
+            }
+
+            // 获取需要移除的令牌ID。
+            long endIndex = Math.min(size - limit, 100);
+            Set<String> tokenSet = conn.zrange("recent:", 0, endIndex - 1);
+            String[] tokens = tokenSet.toArray(new String[tokenSet.size()]);
+
+            // 为那些将要被删除的令牌构建键名。
+            ArrayList<String> sessionKeys = new ArrayList<String>();
+            for (String token : tokens) {
+                sessionKeys.add("viewed:" + token);
+            }
+
+            // 移除最旧的那些令牌。
+            conn.del(sessionKeys.toArray(new String[sessionKeys.size()]));
+            conn.hdel("login:", tokens);
+            conn.zrem("recent:", tokens);
+        }
+    }
+
+}
+

# 案例-购物车

可以使用 HASH 结构来实现购物车功能。

每个用户的购物车，存储了商品 ID 和商品数量的映射。

# 在购物车中添加、删除商品

    public void addToCart(Jedis conn, String session, String item, int count) {
+        if (count <= 0) {
+            // 从购物车里面移除指定的商品。
+            conn.hdel("cart:" + session, item);
+        } else {
+            // 将指定的商品添加到购物车。
+            conn.hset("cart:" + session, item, String.valueOf(count));
+        }
+    }
+

# 清空购物车

在 清理令牌 的基础上，清空会话时，顺便将购物车缓存一并清理。

   while (!quit) {
+        long size = conn.zcard("recent:");
+        if (size <= limit) {
+            try {
+                sleep(1000);
+            } catch (InterruptedException ie) {
+                Thread.currentThread().interrupt();
+            }
+            continue;
+        }
+
+        long endIndex = Math.min(size - limit, 100);
+        Set<String> sessionSet = conn.zrange("recent:", 0, endIndex - 1);
+        String[] sessions = sessionSet.toArray(new String[sessionSet.size()]);
+
+        ArrayList<String> sessionKeys = new ArrayList<String>();
+        for (String sess : sessions) {
+            sessionKeys.add("viewed:" + sess);
+            // 新增加的这行代码用于删除旧会话对应用户的购物车。
+            sessionKeys.add("cart:" + sess);
+        }
+
+        conn.del(sessionKeys.toArray(new String[sessionKeys.size()]));
+        conn.hdel("login:", sessions);
+        conn.zrem("recent:", sessions);
+    }
+

# 案例-页面缓存

大部分网页内容并不会经常改变，但是访问时，后台需要动态计算，这可能耗时较多，此时可以使用 STRING 结构存储页面缓存，

    public String cacheRequest(Jedis conn, String request, Callback callback) {
+        // 对于不能被缓存的请求，直接调用回调函数。
+        if (!canCache(conn, request)) {
+            return callback != null ? callback.call(request) : null;
+        }
+
+        // 将请求转换成一个简单的字符串键，方便之后进行查找。
+        String pageKey = "cache:" + hashRequest(request);
+        // 尝试查找被缓存的页面。
+        String content = conn.get(pageKey);
+
+        if (content == null && callback != null) {
+            // 如果页面还没有被缓存，那么生成页面。
+            content = callback.call(request);
+            // 将新生成的页面放到缓存里面。
+            conn.setex(pageKey, 300, content);
+        }
+
+        // 返回页面。
+        return content;
+    }
+

# 案例-数据行缓存

电商网站可能会有促销、特卖、抽奖等活动，这些活动页面只需要从数据库中加载几行数据，如：用户信息、商品信息。

可以使用 STRING 结构来缓存这些数据，使用 JSON 存储结构化的信息。

此外，需要有两个 ZSET 结构来记录更新缓存的时机：

  • 第一个为调度有序集合；
  • 第二个为延时有序集合。

记录缓存时机：

    public void scheduleRowCache(Jedis conn, String rowId, int delay) {
+        // 先设置数据行的延迟值。
+        conn.zadd("delay:", delay, rowId);
+        // 立即缓存数据行。
+        conn.zadd("schedule:", System.currentTimeMillis() / 1000, rowId);
+    }
+

定时更新数据行缓存：

public class CacheRowsThread extends Thread {
+
+    private Jedis conn;
+
+    private boolean quit;
+
+    public CacheRowsThread() {
+        this.conn = new Jedis("localhost");
+        this.conn.select(15);
+    }
+
+    public void quit() {
+        quit = true;
+    }
+
+    @Override
+    public void run() {
+        Gson gson = new Gson();
+        while (!quit) {
+            // 尝试获取下一个需要被缓存的数据行以及该行的调度时间戳，
+            // 命令会返回一个包含零个或一个元组（tuple）的列表。
+            Set<Tuple> range = conn.zrangeWithScores("schedule:", 0, 0);
+            Tuple next = range.size() > 0 ? range.iterator().next() : null;
+            long now = System.currentTimeMillis() / 1000;
+            if (next == null || next.getScore() > now) {
+                try {
+                    // 暂时没有行需要被缓存，休眠50毫秒后重试。
+                    sleep(50);
+                } catch (InterruptedException ie) {
+                    Thread.currentThread().interrupt();
+                }
+                continue;
+            }
+
+            String rowId = next.getElement();
+            // 获取下一次调度前的延迟时间。
+            double delay = conn.zscore("delay:", rowId);
+            if (delay <= 0) {
+                // 不必再缓存这个行，将它从缓存中移除。
+                conn.zrem("delay:", rowId);
+                conn.zrem("schedule:", rowId);
+                conn.del("inv:" + rowId);
+                continue;
+            }
+
+            // 读取数据行。
+            Inventory row = Inventory.get(rowId);
+            // 更新调度时间并设置缓存值。
+            conn.zadd("schedule:", now + delay, rowId);
+            conn.set("inv:" + rowId, gson.toJson(row));
+        }
+    }
+
+}
+

# 案例-网页分析

网站可以采集用户的访问、交互、购买行为，再分析用户习惯、喜好，从而判断市场行情和潜在商机等。

那么，简单的，如何记录用户在一定时间内访问的商品页面呢？

参考 更新令牌 代码示例，记录用户访问不同商品的浏览次数，并排序。

判断页面是否需要缓存，根据评分判断商品页面是否热门：

    public boolean canCache(Jedis conn, String request) {
+        try {
+            URL url = new URL(request);
+            HashMap<String, String> params = new HashMap<>();
+            if (url.getQuery() != null) {
+                for (String param : url.getQuery().split("&")) {
+                    String[] pair = param.split("=", 2);
+                    params.put(pair[0], pair.length == 2 ? pair[1] : null);
+                }
+            }
+
+            // 尝试从页面里面取出商品ID。
+            String itemId = extractItemId(params);
+            // 检查这个页面能否被缓存以及这个页面是否为商品页面。
+            if (itemId == null || isDynamic(params)) {
+                return false;
+            }
+            // 取得商品的浏览次数排名。
+            Long rank = conn.zrank("viewed:", itemId);
+            // 根据商品的浏览次数排名来判断是否需要缓存这个页面。
+            return rank != null && rank < 10000;
+        } catch (MalformedURLException mue) {
+            return false;
+        }
+    }
+

# 案例-记录日志

可用使用 LIST 结构存储日志数据。

    public void logRecent(Jedis conn, String name, String message, String severity) {
+        String destination = "recent:" + name + ':' + severity;
+        Pipeline pipe = conn.pipelined();
+        pipe.lpush(destination, TIMESTAMP.format(new Date()) + ' ' + message);
+        pipe.ltrim(destination, 0, 99);
+        pipe.sync();
+    }
+

# 案例-统计数据

更新计数器：

    public static final int[] PRECISION = new int[] { 1, 5, 60, 300, 3600, 18000, 86400 };
+
+    public void updateCounter(Jedis conn, String name, int count, long now) {
+        Transaction trans = conn.multi();
+        for (int prec : PRECISION) {
+            long pnow = (now / prec) * prec;
+            String hash = String.valueOf(prec) + ':' + name;
+            trans.zadd("known:", 0, hash);
+            trans.hincrBy("count:" + hash, String.valueOf(pnow), count);
+        }
+        trans.exec();
+    }
+

查看计数器数据：

    public List<Pair<Integer>> getCounter(
+        Jedis conn, String name, int precision) {
+        String hash = String.valueOf(precision) + ':' + name;
+        Map<String, String> data = conn.hgetAll("count:" + hash);
+        List<Pair<Integer>> results = new ArrayList<>();
+        for (Map.Entry<String, String> entry : data.entrySet()) {
+            results.add(new Pair<>(
+                entry.getKey(),
+                Integer.parseInt(entry.getValue())));
+        }
+        Collections.sort(results);
+        return results;
+    }
+

# 案例-查找 IP 所属地

Redis 实现的 IP 所属地查找比关系型数据实现方式更快。

# 载入 IP 数据

IP 地址转为整数值：

    public int ipToScore(String ipAddress) {
+        int score = 0;
+        for (String v : ipAddress.split("\\.")) {
+            score = score * 256 + Integer.parseInt(v, 10);
+        }
+        return score;
+    }
+

创建 IP 地址与城市 ID 之间的映射：

    public void importIpsToRedis(Jedis conn, File file) {
+        FileReader reader = null;
+        try {
+            // 载入 csv 文件数据
+            reader = new FileReader(file);
+            CSVFormat csvFormat = CSVFormat.DEFAULT.withRecordSeparator("\n");
+            CSVParser csvParser = csvFormat.parse(reader);
+            int count = 0;
+            List<CSVRecord> records = csvParser.getRecords();
+            for (CSVRecord line : records) {
+                String startIp = line.get(0);
+                if (startIp.toLowerCase().indexOf('i') != -1) {
+                    continue;
+                }
+                // 将 IP 地址转为整数值
+                int score = 0;
+                if (startIp.indexOf('.') != -1) {
+                    score = ipToScore(startIp);
+                } else {
+                    try {
+                        score = Integer.parseInt(startIp, 10);
+                    } catch (NumberFormatException nfe) {
+                        // 略过文件的第一行以及格式不正确的条目
+                        continue;
+                    }
+                }
+
+                // 构建唯一的城市 ID
+                String cityId = line.get(2) + '_' + count;
+                // 将城市 ID 及其对应的 IP 地址整数值添加到 ZSET
+                conn.zadd("ip2cityid:", score, cityId);
+                count++;
+            }
+        } catch (Exception e) {
+            throw new RuntimeException(e);
+        } finally {
+            try {
+                reader.close();
+            } catch (Exception e) {
+                // ignore
+            }
+        }
+    }
+

存储城市信息：

    public void importCitiesToRedis(Jedis conn, File file) {
+        Gson gson = new Gson();
+        FileReader reader = null;
+        try {
+            // 加载 csv 信息
+            reader = new FileReader(file);
+            CSVFormat csvFormat = CSVFormat.DEFAULT.withRecordSeparator("\n");
+            CSVParser parser = new CSVParser(reader, csvFormat);
+            // String[] line;
+            List<CSVRecord> records = parser.getRecords();
+            for (CSVRecord record : records) {
+
+                if (record.size() < 4 || !Character.isDigit(record.get(0).charAt(0))) {
+                    continue;
+                }
+
+                // 将城市地理信息转为 json 结构，存入 HASH 结构中
+                String cityId = record.get(0);
+                String country = record.get(1);
+                String region = record.get(2);
+                String city = record.get(3);
+                String json = gson.toJson(new String[] { city, region, country });
+                conn.hset("cityid2city:", cityId, json);
+            }
+        } catch (Exception e) {
+            throw new RuntimeException(e);
+        } finally {
+            try {
+                reader.close();
+            } catch (Exception e) {
+                // ignore
+            }
+        }
+    }
+

# 查找 IP 所属城市

操作步骤：

  1. 将要查找的 IP 地址转为整数值；
  2. 查找所有分值小于等于要查找的 IP 地址的地址，取出其中最大分值的那个记录；
  3. 用找到的记录所对应的城市 ID 去检索城市信息。
    public String[] findCityByIp(Jedis conn, String ipAddress) {
+        int score = ipToScore(ipAddress);
+        Set<String> results = conn.zrevrangeByScore("ip2cityid:", score, 0, 0, 1);
+        if (results.size() == 0) {
+            return null;
+        }
+
+        String cityId = results.iterator().next();
+        cityId = cityId.substring(0, cityId.indexOf('_'));
+        return new Gson().fromJson(conn.hget("cityid2city:", cityId), String[].class);
+    }
+

# 案例-服务的发现与配置

# 案例-自动补全

需求：根据用户输入，自动补全信息，如：联系人、商品名等。

  • 典型场景一：社交网站后台记录用户最近联系过的 100 个好友，当用户查找好友时，根据输入的关键字自动补全姓名。
  • 典型场景二：电商网站后台记录用户最近浏览过的 10 件商品，当用户查找商品是，根据输入的关键字自动补全商品名称。

数据模型：使用 Redis 的 LIST 类型存储最近联系人列表。

构建自动补全列表通常有以下操作：

  • 如果指定联系人已经存在于最近联系人列表里，那么从列表里移除他。对应 LREM 命令。
  • 将指定联系人添加到最近联系人列表的最前面。对应 LPUSH 命令。
  • 添加操作完成后，如果联系人列表中的数量超过 100 个，进行裁剪操作。对应 LTRIM 命令。

# 案例-广告定向

# 案例-职位搜索

需求：在一个招聘网站上，求职者有自己的技能清单；用人公司的职位有必要的技能清单。用人公司需要查询满足自己职位要求的求职者；求职者需要查询自己可以投递简历的职位。

关键数据模型：使用 SET 类型存储求职者的技能列表，使用 SET 类型存储职位的技能列表。

关键操作：使用 SDIFF 命令对比两个 SET 的差异，返回 empty 表示匹配要求。

redis cli 示例：

# -----------------------------------------------------------
+# Redis 职位搜索数据模型示例
+# -----------------------------------------------------------
+
+# （1）职位技能表：使用 set 存储
+# job:001 职位添加 4 种技能
+SADD job:001 skill:001
+SADD job:001 skill:002
+SADD job:001 skill:003
+SADD job:001 skill:004
+
+# job:002 职位添加 3 种技能
+SADD job:002 skill:001
+SADD job:002 skill:002
+SADD job:002 skill:003
+
+# job:003 职位添加 2 种技能
+SADD job:003 skill:001
+SADD job:003 skill:003
+
+# 查看
+SMEMBERS job:001
+SMEMBERS job:002
+SMEMBERS job:003
+
+# （2）求职者技能表：使用 set 存储
+SADD interviewee:001 skill:001
+SADD interviewee:001 skill:003
+
+SADD interviewee:002 skill:001
+SADD interviewee:002 skill:002
+SADD interviewee:002 skill:003
+SADD interviewee:002 skill:004
+SADD interviewee:002 skill:005
+
+# 查看
+SMEMBERS interviewee:001
+SMEMBERS interviewee:002
+
+# （3）求职者遍历查找自己符合要求的职位（返回结果为 empty 表示要求的技能全部命中）
+# 比较职位技能清单和求职者技能清单的差异
+SDIFF job:001 interviewee:001
+SDIFF job:002 interviewee:001
+SDIFF job:003 interviewee:001
+
+SDIFF job:001 interviewee:002
+SDIFF job:002 interviewee:002
+SDIFF job:003 interviewee:002
+
+# （4）用人公司根据遍历查找符合自己职位要求的求职者（返回结果为 empty 表示要求的技能全部命中）
+# 比较职位技能清单和求职者技能清单的差异
+SDIFF interviewee:001 job:001
+SDIFF interviewee:002 job:001
+
+SDIFF interviewee:001 job:002
+SDIFF interviewee:002 job:002
+
+SDIFF interviewee:001 job:003
+SDIFF interviewee:002 job:003
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#KV数据库#Redis#数据类型
上次更新: 2023/06/29, 22:27:04
Redis 应用指南
Redis 持久化

+ ← + Redis 持久化→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/f1f151/index.html b/pages/f1f151/index.html new file mode 100644 index 00000000..188c725a --- /dev/null +++ b/pages/f1f151/index.html @@ -0,0 +1,81 @@ + + + + + + Mysql 锁 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-09-07
目录

Mysql 锁

# Mysql 锁

img

# 悲观锁和乐观锁

确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性，乐观锁和悲观锁是并发控制主要采用的技术手段。

  • 悲观锁 - 假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作 +
    • 在查询完数据的时候就把事务锁起来，直到提交事务（COMMIT）
    • 实现方式：使用数据库中的锁机制。
  • 乐观锁 - 假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。 +
    • 在修改数据的时候把事务锁起来，通过 version 的方式来进行锁定
    • 实现方式：使用 version 版本或者时间戳。

【示例】乐观锁示例

商品 goods 表中有一个字段 status，status 为 1 代表商品未被下单，status 为 2 代表商品已经被下单，那么我们对某个商品下单时必须确保该商品 status 为 1。假设商品的 id 为 1。

select (status,status,version) from t_goods where id=#{id}
+
+update t_goods
+set status=2,version=version+1
+where id=#{id} and version=#{version};
+

更详细的乐观锁说可以参考：使用 mysql 乐观锁解决并发问题 (opens new window)

# 表级锁和行级锁

从数据库的锁粒度来看，MySQL 中提供了两种封锁粒度：行级锁和表级锁。

  • 表级锁（table lock） - 锁定整张表。用户对表进行写操作前，需要先获得写锁，这会阻塞其他用户对该表的所有读写操作。只有没有写锁时，其他用户才能获得读锁，读锁之间不会相互阻塞。
  • 行级锁（row lock） - 锁定指定的行记录。这样其它进程还是可以对同一个表中的其它记录进行操作。

应该尽量只锁定需要修改的那部分数据，而不是所有的资源。锁定的数据量越少，锁竞争的发生频率就越小，系统的并发程度就越高。但是加锁需要消耗资源，锁的各种操作（包括获取锁、释放锁、以及检查锁状态）都会增加系统开销。因此锁粒度越小，系统开销就越大。

在选择锁粒度时，需要在锁开销和并发程度之间做一个权衡。

在 InnoDB 中，行锁是通过给索引上的索引项加锁来实现的。如果没有索引，InnoDB 将会通过隐藏的聚簇索引来对记录加锁。

# 读写锁

  • 独享锁（Exclusive），简写为 X 锁，又称写锁。使用方式：SELECT ... FOR UPDATE;
  • 共享锁（Shared），简写为 S 锁，又称读锁。使用方式：SELECT ... LOCK IN SHARE MODE;

写锁和读锁的关系，简言之：独享锁存在，其他事务就不能做任何操作。

InnoDB 下的行锁、间隙锁、next-key 锁统统属于独享锁。

# 意向锁

当存在表级锁和行级锁的情况下，必须先申请意向锁（表级锁，但不是真的加锁），再获取行级锁。使用意向锁（Intention Locks）可以更容易地支持多粒度封锁。

意向锁是 InnoDB 自动加的，不需要用户干预。

在存在行级锁和表级锁的情况下，事务 T 想要对表 A 加 X 锁，就需要先检测是否有其它事务对表 A 或者表 A 中的任意一行加了锁，那么就需要对表 A 的每一行都检测一次，这是非常耗时的。

意向锁规定：

  • IX/IS 是表锁；
  • X/S 是行锁。
  • 一个事务在获得某个数据行的 S 锁之前，必须先获得表的 IS 锁或者更强的锁；
  • 一个事务在获得某个数据行的 X 锁之前，必须先获得表的 IX 锁。

通过引入意向锁，事务 T 想要对表 A 加 X 锁，只需要先检测是否有其它事务对表 A 加了 X/IX/S/IS 锁，如果加了就表示有其它事务正在使用这个表或者表中某一行的锁，因此事务 T 加 X 锁失败。

各种锁的兼容关系如下：

- X IX S IS
X ❌ ❌ ❌ ❌
IX ❌ ✔️ ❌ ✔️
S ❌ ❌ ✔️ ✔️
IS ❌ ✔️ ✔️ ✔️

解释如下：

  • 任意 IS/IX 锁之间都是兼容的，因为它们只表示想要对表加锁，而不是真正加锁；
  • 这里兼容关系针对的是表级锁，而表级的 IX 锁和行级的 X 锁兼容，两个事务可以对两个数据行加 X 锁。（事务 T1 想要对数据行 R1 加 X 锁，事务 T2 想要对同一个表的数据行 R2 加 X 锁，两个事务都需要对该表加 IX 锁，但是 IX 锁是兼容的，并且 IX 锁与行级的 X 锁也是兼容的，因此两个事务都能加锁成功，对同一个表中的两个数据行做修改。）

# MVCC

多版本并发控制（Multi-Version Concurrency Control, MVCC）可以视为行级锁的一个变种。它在很多情况下都避免了加锁操作，因此开销更低。不仅是 Mysql，包括 Oracle、PostgreSQL 等其他数据库都实现了各自的 MVCC，实现机制没有统一标准。

MVCC 是 InnoDB 存储引擎实现隔离级别的一种具体方式，用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行，要求很低，无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。

# MVCC 思想

加锁能解决多个事务同时执行时出现的并发一致性问题。在实际场景中读操作往往多于写操作，因此又引入了读写锁来避免不必要的加锁操作，例如读和读没有互斥关系。读写锁中读和写操作仍然是互斥的。

MVCC 的思想是：

  • 保存数据在某个时间点的快照，写操作（DELETE、INSERT、UPDATE）更新最新的版本快照；而读操作去读旧版本快照，没有互斥关系。这一点和 CopyOnWrite 类似。
  • 脏读和不可重复读最根本的原因是事务读取到其它事务未提交的修改。在事务进行读取操作时，为了解决脏读和不可重复读问题，MVCC 规定只能读取已经提交的快照。当然一个事务可以读取自身未提交的快照，这不算是脏读。

# 版本号

InnoDB 的 MVCC 实现是：在每行记录后面保存两个隐藏列，一个列保存行的创建时间，另一个列保存行的过期时间（这里的时间是指系统版本号）。每开始一个新事务，系统版本号会自动递增，事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。

  • 系统版本号 SYS_ID：是一个递增的数字，每开始一个新的事务，系统版本号就会自动递增。
  • 事务版本号 TRX_ID ：事务开始时的系统版本号。

# Undo 日志

MVCC 的多版本指的是多个版本的快照，快照存储在 Undo 日志中，该日志通过回滚指针 ROLL_PTR 把一个数据行的所有快照连接起来。

例如在 MySQL 创建一个表 t，包含主键 id 和一个字段 x。我们先插入一个数据行，然后对该数据行执行两次更新操作。

INSERT INTO t(id, x) VALUES(1, "a");
+UPDATE t SET x="b" WHERE id=1;
+UPDATE t SET x="c" WHERE id=1;
+

因为没有使用 START TRANSACTION 将上面的操作当成一个事务来执行，根据 MySQL 的 AUTOCOMMIT 机制，每个操作都会被当成一个事务来执行，所以上面的操作总共涉及到三个事务。快照中除了记录事务版本号 TRX_ID 和操作之外，还记录了一个 bit 的 DEL 字段，用于标记是否被删除。

INSERT、UPDATE、DELETE 操作会创建一个日志，并将事务版本号 TRX_ID 写入。DELETE 可以看成是一个特殊的 UPDATE，还会额外将 DEL 字段设置为 1。

# ReadView

MVCC 维护了一个一致性读视图 consistent read view ，主要包含了当前系统未提交的事务列表 TRX_IDs {TRX_ID_1, TRX_ID_2, ...}，还有该列表的最小值 TRX_ID_MIN 和 TRX_ID_MAX。

img

这样，对于当前事务的启动瞬间来说，一个数据版本的 row trx_id，有以下几种可能：

  1. 如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；
  2. 如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的；
  3. 如果落在黄色部分，那就包括两种情况 +a. 若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见； +b. 若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见。

在进行 SELECT 操作时，根据数据行快照的 TRX_ID 与 TRX_ID_MIN 和 TRX_ID_MAX 之间的关系，从而判断数据行快照是否可以使用：

  • TRX_ID < TRX_ID_MIN，表示该数据行快照时在当前所有未提交事务之前进行更改的，因此可以使用。
  • TRX_ID > TRX_ID_MAX，表示该数据行快照是在事务启动之后被更改的，因此不可使用。
  • TRX_ID_MIN <= TRX_ID <= TRX_ID_MAX，需要根据隔离级别再进行判断： +
    • 提交读：如果 TRX_ID 在 TRX_IDs 列表中，表示该数据行快照对应的事务还未提交，则该快照不可使用。否则表示已经提交，可以使用。
    • 可重复读：都不可以使用。因为如果可以使用的话，那么其它事务也可以读到这个数据行快照并进行修改，那么当前事务再去读这个数据行得到的值就会发生改变，也就是出现了不可重复读问题。

在数据行快照不可使用的情况下，需要沿着 Undo Log 的回滚指针 ROLL_PTR 找到下一个快照，再进行上面的判断。

# 快照读与当前读

快照读

MVCC 的 SELECT 操作是快照中的数据，不需要进行加锁操作。

SELECT * FROM table ...;
+

当前读

MVCC 其它会对数据库进行修改的操作（INSERT、UPDATE、DELETE）需要进行加锁操作，从而读取最新的数据。可以看到 MVCC 并不是完全不用加锁，而只是避免了 SELECT 的加锁操作。

INSERT;
+UPDATE;
+DELETE;
+

在进行 SELECT 操作时，可以强制指定进行加锁操作。以下第一个语句需要加 S 锁，第二个需要加 X 锁。

SELECT * FROM table WHERE ? lock in share mode;
+SELECT * FROM table WHERE ? for update;
+

# 行锁

行锁的具体实现算法有三种：record lock、gap lock 以及 next-key lock。

  • Record Lock - 行锁对索引项加锁，若没有索引则使用表锁。
  • Gap Lock - 对索引项之间的间隙加锁。锁定索引之间的间隙，但是不包含索引本身。例如当一个事务执行以下语句，其它事务就不能在 t.c 中插入 15：SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;。在 MySQL 中，gap lock 默认是开启的，即 innodb_locks_unsafe_for_binlog 参数值是 disable 的，且 MySQL 中默认的是 RR 事务隔离级别。
  • Next-key lock -它是 Record Lock 和 Gap Lock 的结合，不仅锁定一个记录上的索引，也锁定索引之间的间隙。它锁定一个前开后闭区间。

只在可重复读或以上隔离级别下的特定操作才会取得 gap lock 或 next-key lock。在 Select、Update 和 Delete 时，除了基于唯一索引的查询之外，其它索引查询时都会获取 gap lock 或 next-key lock，即锁住其扫描的范围。主键索引也属于唯一索引，所以主键索引是不会使用 gap lock 或 next-key lock。

MVCC 不能解决幻读问题，Next-Key 锁就是为了解决幻读问题。在可重复读（REPEATABLE READ）隔离级别下，使用 MVCC + Next-Key 锁 可以解决幻读问题。

索引分为主键索引和非主键索引两种，如果一条 SQL 语句操作了主键索引，MySQL 就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL 会先锁定该非主键索引，再锁定相关的主键索引。在 UPDATE、DELETE 操作时，MySQL 不仅锁定 WHERE 条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的 next-key lock。

当两个事务同时执行，一个锁住了主键索引，在等待其他相关索引。另一个锁定了非主键索引，在等待主键索引。这样就会发生死锁。发生死锁后，InnoDB 一般都可以检测到，并使一个事务释放锁回退，另一个获取锁完成事务。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#Mysql#锁
上次更新: 2023/06/29, 22:27:04
Mysql 事务
Mysql 索引

+ ← + Mysql 索引→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/f27c0c/index.html b/pages/f27c0c/index.html new file mode 100644 index 00000000..ad35964a --- /dev/null +++ b/pages/f27c0c/index.html @@ -0,0 +1,153 @@ + + + + + + H2 应用指南 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2019-08-22
目录

H2 应用指南

# H2 应用指南

# 概述

H2 是一个开源的嵌入式数据库引擎，采用 java 语言编写，不受平台的限制。同时 H2 提供了一个十分方便的 web 控制台用于操作和管理数据库内容。H2 还提供兼容模式，可以兼容一些主流的数据库，因此采用 H2 作为开发期的数据库非常方便。

# 使用说明

# H2 控制台应用

H2 允许用户通过浏览器接口方式访问 SQL 数据库。

  1. 进入官方下载地址 (opens new window)，选择合适版本，下载并安装到本地。
  2. 启动方式：在 bin 目录下，双击 jar 包；执行 java -jar h2*.jar；执行脚本：h2.bat 或 h2.sh。
  3. 在浏览器中访问：http://localhost:8082，应该可以看到下图中的页面：

img

点击 Connect ，可以进入操作界面：

img

操作界面十分简单，不一一细说。

# 嵌入式应用

# JDBC API

Connection conn = DriverManager.
+    getConnection("jdbc:h2:~/test");
+conn.close();
+

详见：Using the JDBC API (opens new window)

# 连接池

import org.h2.jdbcx.JdbcConnectionPool;
+JdbcConnectionPool cp = JdbcConnectionPool.
+create("jdbc:h2:~/test", "sa", "sa");
+Connection conn = cp.getConnection();
+conn.close(); cp.dispose();
+

详见：Connection Pool (opens new window)

# Maven

<dependency>
+    <groupId>com.h2database</groupId>
+    <artifactId>h2</artifactId>
+    <version>1.4.197</version>
+</dependency>
+

详见：Maven 2 (opens new window)

# Hibernate

hibernate.cfg.xml (or use the HSQLDialect):

<property name="dialect">
+    org.hibernate.dialect.H2Dialect
+</property>
+

详见：Hibernate (opens new window)

Datasource class: org.h2.jdbcx.JdbcDataSource oracle.toplink.essentials.platform.database.H2Platform

详见：TopLink and Glassfish (opens new window)

# 运行方式

# 嵌入式

数据库持久化存储为单个文件。

连接字符串：\~/.h2/DBName 表示数据库文件的存储位置，如果第一次连接则会自动创建数据库。

  • jdbc:h2:\~/test - 'test' 在用户根目录下
  • jdbc:h2:/data/test - 'test' 在 /data 目录下
  • jdbc:h2:test - 'test' 在当前工作目录

# 内存式

数据库只在内存中运行，关闭连接后数据库将被清空，适合测试环境

连接字符串：jdbc:h2:mem:DBName;DB_CLOSE_DELAY=-1

如果不指定 DBName，则以私有方式启动，只允许一个连接。

  • jdbc:h2:mem:test - 一个进程中有多个连接
  • jdbc:h2:mem: - 未命名的私有库，一个连接

# 服务模式

H2 支持三种服务模式：

  • web server：此种运行方式支持使用浏览器访问 H2 Console
  • TCP server：支持客户端/服务器端的连接方式
  • PG server：支持 PostgreSQL 客户端

启动 tcp 服务连接字符串示例：

  • jdbc:h2:tcp://localhost/\~/test - 用户根目录
  • jdbc:h2:tcp://localhost//data/test - 绝对路径

# 启动服务

执行 java -cp *.jar org.h2.tools.Server

执行如下命令，获取选项列表及默认值

java -cp h2*.jar org.h2.tools.Server -?
+

常见的选项如下：

  • -web：启动支持 H2 Console 的服务
  • -webPort <port>：服务启动端口，默认为 8082
  • -browser：启动 H2 Console web 管理页面
  • -tcp：使用 TCP server 模式启动
  • -pg：使用 PG server 模式启动

# 设置

  • jdbc:h2:..;MODE=MySQL 兼容模式（或 HSQLDB 等）
  • jdbc:h2:..;TRACE_LEVEL_FILE=3 记录到 *.trace.db

# 连接字符串参数

  • DB_CLOSE_DELAY - 要求最后一个正在连接的连接断开后，不要关闭数据库
  • MODE=MySQL - 兼容模式，H2 兼容多种数据库，该值可以为：DB2、Derby、HSQLDB、MSSQLServer、MySQL、Oracle、PostgreSQL
  • AUTO_RECONNECT=TRUE - 连接丢失后自动重新连接
  • AUTO_SERVER=TRUE - 启动自动混合模式，允许开启多个连接，该参数不支持在内存中运行模式
  • TRACE_LEVEL_SYSTEM_OUT、TRACE_LEVEL_FILE - 输出跟踪日志到控制台或文件， 取值 0 为 OFF，1 为 ERROR（默认值），2 为 INFO，3 为 DEBUG
  • SET TRACE_MAX_FILE_SIZE mb - 设置跟踪日志文件的大小，默认为 16M

# maven 方式

此外，使用 maven 也可以启动 H2 服务。添加以下插件

<plugin>
+  <groupId>org.codehaus.mojo</groupId>
+  <artifactId>exec-maven-plugin</artifactId>
+  <executions>
+    <execution>
+      <goals>
+        <goal>java</goal>
+      </goals>
+    </execution>
+  </executions>
+  <configuration>
+    <mainClass>org.h2.tools.Server</mainClass>
+    <arguments>
+      <argument>-web</argument>
+      <argument>-webPort</argument>
+      <argument>8090</argument>
+      <argument>-browser</argument>
+    </arguments>
+  </configuration>
+</plugin>
+

在命令行中执行如下命令启动 H2 Console

mvn exec:java
+

或者建立一个 bat 文件

@echo off
+call mvn exec:java
+pause
+

此操作相当于执行了如下命令：

java -jar h2-1.3.168.jar -web -webPort 8090 -browser
+

# Spring 整合 H2

（1）添加依赖

<dependency>
+  <groupId>com.h2database</groupId>
+  <artifactId>h2</artifactId>
+  <version>1.4.194</version>
+</dependency>
+

（2）spring 配置

<?xml version="1.0" encoding="UTF-8"?>
+<beans xmlns="http://www.springframework.org/schema/beans"
+       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+       xmlns:jdbc="http://www.springframework.org/schema/jdbc"
+       xsi:schemaLocation="http://www.springframework.org/schema/beans
+            http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
+            http://www.springframework.org/schema/jdbc
+            http://www.springframework.org/schema/jdbc/spring-jdbc.xsd">
+
+  <!--配置数据源-->
+  <bean id="dataSource" class="org.h2.jdbcx.JdbcConnectionPool"
+        destroy-method="dispose">
+    <constructor-arg>
+      <bean class="org.h2.jdbcx.JdbcDataSource">
+        <!-- 内存模式 -->
+        <property name="URL" value="jdbc:h2:mem:test"/>
+        <!-- 文件模式 -->
+        <!-- <property name="URL" value="jdbc:h2:testRestDB" /> -->
+        <property name="user" value="root"/>
+        <property name="password" value="root"/>
+      </bean>
+    </constructor-arg>
+  </bean>
+
+  <!-- JDBC模板 -->
+  <bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
+    <constructor-arg ref="dataSource"/>
+  </bean>
+  <bean id="myJdbcTemplate" class="org.zp.notes.spring.jdbc.MyJdbcTemplate">
+    <property name="jdbcTemplate" ref="jdbcTemplate"/>
+  </bean>
+
+  <!-- 初始化数据表结构 -->
+  <jdbc:initialize-database data-source="dataSource" ignore-failures="ALL">
+    <jdbc:script location="classpath:sql/h2/create_table_student.sql"/>
+  </jdbc:initialize-database>
+</beans>
+

# H2 SQL

# SELECT

img

# INSERT

img

# UPDATE

img

# DELETE

img

# BACKUP

img

# EXPLAIN

img

7、MERGE +img

# RUNSCRIPT

运行 sql 脚本文件

img

# SCRIPT

根据数据库创建 sql 脚本

img

# SHOW

img

# ALTER

# ALTER INDEX RENAME

img

# ALTER SCHEMA RENAME

img

# ALTER SEQUENCE

img

# ALTER TABLE

img

# 增加约束

img

# 修改列

img

# 删除列

img

# 删除序列

img

# ALTER USER

# 修改用户名

img

# 修改用户密码

img

# ALTER VIEW

img

# COMMENT

img

# CREATE CONSTANT

img

# CREATE INDEX

img

# CREATE ROLE

img

# CREATE SCHEMA

img

# CREATE SEQUENCE

img

# CREATE TABLE

img

# CREATE TRIGGER

img

# CREATE USER

img

# CREATE VIEW

img

# DROP

img

# GRANT RIGHT

给 schema 授权授权

img

给 schema 授权给 schema 授权

img

# 复制角色的权限

img

# REVOKE RIGHT

# 移除授权

img

# 移除角色具有的权限

img

# ROLLBACK

# 从某个还原点（savepoint）回滚

img

# 回滚事务

img

# 创建 savepoint

img

# 数据类型

img

# INT Type

img

# 集群

H2 支持两台服务器运行两个数据库成为集群，两个数据库互为备份，如果一个服务器失效，另一个服务器仍然可以工作。另外只有服务模式支持集群配置。

H2 可以通过 CreateCluster 工具创建集群，示例步骤如下（在在一台服务器上模拟两个数据库组成集群）：

  • 创建目录 +
    • 创建两个服务器工作的目录
  • 启动 tcp 服务 +
    • 执行如下命令分别在 9101、9102 端口启动两个使用 tcp 服务模式的数据库
  • 使用 CreateCluster 工具创建集群 +
    • 如果两个数据库不存在，该命令将会自动创建数据库。如果一个数据库失效，可以先删除坏的数据库文件，重新启动数据库，然后重新运行 CreateCluster 工具
  • 连接数据库现在可以使用如下连接字符串连接集群数据库 +
    • 监控集群运行状态
    • 可以使用如下命令查看配置的集群服务器是否都在运行
  • 限制 +
    • H2 的集群并不支持针对事务的负载均衡，所以很多操作会使两个数据库产生不一致的结果
  • 执行如下操作时请小心： +
    • 自动增长列和标识列不支持集群，当插入数据时，序列值需要手动创建不支持 SET AUTOCOMMIT FALSE 语句；
    • 如果需要设置成为不自动提交，可以执行方法 Connection.setAutoCommit(false)

# 参考资料

# 🚪 传送门

| 钝悟的博客 (opens new window) | db-tutorial 首页 (opens new window) |

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#H2
上次更新: 2023/06/29, 22:27:04
PostgreSQL 应用指南
sqlite

+ ← + sqlite→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/f808fc/index.html b/pages/f808fc/index.html new file mode 100644 index 00000000..875f1af9 --- /dev/null +++ b/pages/f808fc/index.html @@ -0,0 +1,87 @@ + + + + + + HBase 运维 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2019-05-07
目录

HBase 运维

# HBase 运维

# 配置文件

  • backup-masters - 默认情况下不存在。列出主服务器应在其上启动备份主进程的主机，每行一个主机。
  • hadoop-metrics2-hbase.properties - 用于连接 HBase Hadoop 的 Metrics2 框架。
  • hbase-env.cmd and hbase-env.sh - 用于 Windows 和 Linux / Unix 环境的脚本，用于设置 HBase 的工作环境，包括 Java，Java 选项和其他环境变量的位置。
  • hbase-policy.xml - RPC 服务器用于对客户端请求进行授权决策的默认策略配置文件。仅在启用 HBase 安全性时使用。
  • hbase-site.xml - 主要的 HBase 配置文件。此文件指定覆盖 HBase 默认配置的配置选项。您可以在 docs / hbase-default.xml 中查看（但不要编辑）默认配置文件。您还可以在 HBase Web UI 的 HBase 配置选项卡中查看群集的整个有效配置（默认值和覆盖）。
  • log4j.properties - log4j 日志配置。
  • regionservers - 包含应在 HBase 集群中运行 RegionServer 的主机列表。默认情况下，此文件包含单个条目 localhost。它应包含主机名或 IP 地址列表，每行一个，并且如果群集中的每个节点将在其 localhost 接口上运行 RegionServer，则应仅包含 localhost。

# 环境要求

  • Java +
    • HBase 2.0+ 要求 JDK8+
    • HBase 1.2+ 要求 JDK7+
  • SSH - 环境要支持 SSH
  • DNS - 环境中要在 hosts 配置本机 hostname 和本机 IP
  • NTP - HBase 集群的时间要同步，可以配置统一的 NTP
  • 平台 - 生产环境不推荐部署在 Windows 系统中
  • Hadoop - 依赖 Hadoop 配套版本
  • Zookeeper - 依赖 Zookeeper 配套版本

# 运行模式

# 单点

hbase-site.xml 配置如下：

<configuration>
+  <property>
+    <name>hbase.rootdir</name>
+    <value>hdfs://namenode.example.org:8020/hbase</value>
+  </property>
+  <property>
+    <name>hbase.cluster.distributed</name>
+    <value>false</value>
+  </property>
+</configuration>
+

# 分布式

hbase-site.xm 配置如下：

<configuration>
+  <property>
+    <name>hbase.rootdir</name>
+    <value>hdfs://namenode.example.org:8020/hbase</value>
+  </property>
+  <property>
+    <name>hbase.cluster.distributed</name>
+    <value>true</value>
+  </property>
+  <property>
+    <name>hbase.zookeeper.quorum</name>
+    <value>node-a.example.com,node-b.example.com,node-c.example.com</value>
+  </property>
+</configuration>
+

# 引用和引申

# 扩展阅读

+
+ +
📝 帮助改善此页面！ (opens new window)
#大数据#HBase#运维
上次更新: 2023/06/29, 22:27:04
HBase Java API 管理功能
HBase 命令

+ ← + HBase 命令→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/f89f66/index.html b/pages/f89f66/index.html new file mode 100644 index 00000000..78c6fff6 --- /dev/null +++ b/pages/f89f66/index.html @@ -0,0 +1,525 @@ + + + + + + Elasticsearch 聚合 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2022-01-19
目录

Elasticsearch 聚合

# Elasticsearch 聚合

Elasticsearch 是一个分布式的全文搜索引擎，索引和搜索是 Elasticsearch 的基本功能。事实上，Elasticsearch 的聚合（Aggregations）功能也十分强大，允许在数据上做复杂的分析统计。Elasticsearch 提供的聚合分析功能主要有指标聚合(metrics aggregations)、桶聚合(bucket aggregations)、管道聚合(pipeline aggregations) 和 矩阵聚合(matrix aggregations) 四大类，管道聚合和矩阵聚合官方说明是在试验阶段，后期会完全更改或者移除，这里不再对管道聚合和矩阵聚合进行讲解。

# 聚合的具体结构

所有的聚合，无论它们是什么类型，都遵从以下的规则。

  • 使用查询中同样的 JSON 请求来定义它们，而且你是使用键 aggregations 或者是 aggs 来进行标记。需要给每个聚合起一个名字，指定它的类型以及和该类型相关的选项。
  • 它们运行在查询的结果之上。和查询不匹配的文档不会计算在内，除非你使用 global 聚集将不匹配的文档囊括其中。
  • 可以进一步过滤查询的结果，而不影响聚集。

以下是聚合的基本结构：

"aggregations" : { <!-- 最外层的聚合键，也可以缩写为 aggs -->
+    "<aggregation_name>" : { <!-- 聚合的自定义名字 -->
+        "<aggregation_type>" : { <!-- 聚合的类型，指标相关的，如 max、min、avg、sum，桶相关的 terms、filter 等 -->
+            <aggregation_body> <!-- 聚合体：对哪些字段进行聚合，可以取字段的值，也可以是脚本计算的结果 -->
+        }
+        [,"meta" : {  [<meta_data_body>] } ]? <!-- 元 -->
+        [,"aggregations" : { [<sub_aggregation>]+ } ]? <!-- 在聚合里面在定义子聚合 -->
+    }
+    [,"<aggregation_name_2>" : { ... } ]* <!-- 聚合的自定义名字 2 -->
+}
+
  • 在最上层有一个 aggregations 的键，可以缩写为 aggs。
  • 在下面一层，需要为聚合指定一个名字。可以在请求的返回中看到这个名字。在同一个请求中使用多个聚合时，这一点非常有用，它让你可以很容易地理解每组结果的含义。
  • 最后，必须要指定聚合的类型。

关于聚合分析的值来源，可以取字段的值，也可以是脚本计算的结果。

但是用脚本计算的结果时，需要注意脚本的性能和安全性；尽管多数聚集类型允许使用脚本，但是脚本使得聚集变得缓慢，因为脚本必须在每篇文档上运行。为了避免脚本的运行，可以在索引阶段进行计算。

此外，脚本也可以被人可能利用进行恶意代码攻击，尽量使用沙盒（sandbox）内的脚本语言。

示例：查询所有球员的平均年龄是多少，并对球员的平均薪水加 188（也可以理解为每名球员加 188 后的平均薪水）。

POST /player/_search?size=0
+{
+  "aggs": {
+    "avg_age": {
+      "avg": {
+        "field": "age"
+      }
+    },
+    "avg_salary_188": {
+      "avg": {
+        "script": {
+          "source": "doc.salary.value + 188"
+        }
+      }
+    }
+  }
+}
+

# 指标聚合

指标聚合（又称度量聚合）主要从不同文档的分组中提取统计数据，或者，从来自其他聚合的文档桶来提取统计数据。

这些统计数据通常来自数值型字段，如最小或者平均价格。用户可以单独获取每项统计数据，或者也可以使用 stats 聚合来同时获取它们。更高级的统计数据，如平方和或者是标准差，可以通过 extended stats 聚合来获取。

# Max Aggregation

Max Aggregation 用于最大值统计。例如，统计 sales 索引中价格最高的是哪本书，并且计算出对应的价格的 2 倍值，查询语句如下：

GET /sales/_search?size=0
+{
+  "aggs" : {
+    "max_price" : {
+      "max" : {
+        "field" : "price"
+      }
+    },
+    "max_price_2" : {
+      "max" : {
+        "field" : "price",
+        "script": {
+          "source": "_value * 2.0"
+        }
+      }
+    }
+  }
+}
+

指定的 field，在脚本中可以用 _value 取字段的值。

聚合结果如下：

{
+  ...
+  "aggregations": {
+    "max_price": {
+      "value": 188.0
+    },
+    "max_price_2": {
+      "value": 376.0
+    }
+  }
+}
+

# Min Aggregation

Min Aggregation 用于最小值统计。例如，统计 sales 索引中价格最低的是哪本书，查询语句如下：

GET /sales/_search?size=0
+{
+  "aggs" : {
+    "min_price" : {
+      "min" : {
+        "field" : "price"
+      }
+    }
+  }
+}
+

聚合结果如下：

{
+  ...
+  "aggregations": {
+    "min_price": {
+      "value": 18.0
+    }
+  }
+}
+

# Avg Aggregation

Avg Aggregation 用于计算平均值。例如，统计 exams 索引中考试的平均分数，如未存在分数，默认为 60 分，查询语句如下：

GET /exams/_search?size=0
+{
+  "aggs" : {
+    "avg_grade" : {
+      "avg" : {
+        "field" : "grade",
+        "missing": 60
+      }
+    }
+  }
+}
+

如果指定字段没有值，可以通过 missing 指定默认值；若未指定默认值，缺失该字段值的文档将被忽略（计算）。

聚合结果如下：

{
+  ...
+  "aggregations": {
+    "avg_grade": {
+      "value": 78.0
+    }
+  }
+}
+

除了常规的平均值聚合计算外，elasticsearch 还提供了加权平均值的聚合计算，详情参见 Elasticsearch 指标聚合之 Weighted Avg Aggregation (opens new window)。

# Sum Aggregation

Sum Aggregation 用于计算总和。例如，统计 sales 索引中 type 字段中匹配 hat 的价格总和，查询语句如下：

GET /exams/_search?size=0
+{
+  "query" : {
+    "constant_score" : {
+      "filter" : {
+        "match" : { "type" : "hat" }
+      }
+    }
+  },
+  "aggs" : {
+    "hat_prices" : {
+      "sum" : { "field" : "price" }
+    }
+  }
+}
+

聚合结果如下：

{
+  ...
+  "aggregations": {
+    "hat_prices": {
+      "value": 567.0
+    }
+  }
+}
+

# Value Count Aggregation

Value Count Aggregation 可按字段统计文档数量。例如，统计 books 索引中包含 author 字段的文档数量，查询语句如下：

GET /books/_search?size=0
+{
+  "aggs" : {
+    "doc_count" : {
+      "value_count" : { "field" : "author" }
+    }
+  }
+}
+

聚合结果如下：

{
+  ...
+  "aggregations": {
+    "doc_count": {
+      "value": 5
+    }
+  }
+}
+

# Cardinality Aggregation

Cardinality Aggregation 用于基数统计，其作用是先执行类似 SQL 中的 distinct 操作，去掉集合中的重复项，然后统计去重后的集合长度。例如，在 books 索引中对 language 字段进行 cardinality 操作可以统计出编程语言的种类数，查询语句如下：

GET /books/_search?size=0
+{
+  "aggs" : {
+    "all_lan" : {
+      "cardinality" : { "field" : "language" }
+    },
+    "title_cnt" : {
+      "cardinality" : { "field" : "title.keyword" }
+    }
+  }
+}
+

假设 title 字段为文本类型（text），去重时需要指定 keyword，表示把 title 作为整体去重，即不分词统计。

聚合结果如下：

{
+  ...
+  "aggregations": {
+    "all_lan": {
+      "value": 8
+    },
+    "title_cnt": {
+      "value": 18
+    }
+  }
+}
+

# Stats Aggregation

Stats Aggregation 用于基本统计，会一次返回 count、max、min、avg 和 sum 这 5 个指标。例如，在 exams 索引中对 grade 字段进行分数相关的基本统计，查询语句如下：

GET /exams/_search?size=0
+{
+  "aggs" : {
+    "grades_stats" : {
+      "stats" : { "field" : "grade" }
+    }
+  }
+}
+

聚合结果如下：

{
+  ...
+  "aggregations": {
+    "grades_stats": {
+      "count": 2,
+      "min": 50.0,
+      "max": 100.0,
+      "avg": 75.0,
+      "sum": 150.0
+    }
+  }
+}
+

# Extended Stats Aggregation

Extended Stats Aggregation 用于高级统计，和基本统计功能类似，但是会比基本统计多出以下几个统计结果，sum_of_squares（平方和）、variance（方差）、std_deviation（标准差）、std_deviation_bounds（平均值加/减两个标准差的区间）。在 exams 索引中对 grade 字段进行分数相关的高级统计，查询语句如下：

GET /exams/_search?size=0
+{
+  "aggs" : {
+    "grades_stats" : {
+      "extended_stats" : { "field" : "grade" }
+    }
+  }
+}
+

聚合结果如下：

{
+  ...
+  "aggregations": {
+    "grades_stats": {
+      "count": 2,
+      "min": 50.0,
+      "max": 100.0,
+      "avg": 75.0,
+      "sum": 150.0,
+      "sum_of_squares": 12500.0,
+      "variance": 625.0,
+      "std_deviation": 25.0,
+      "std_deviation_bounds": {
+        "upper": 125.0,
+        "lower": 25.0
+      }
+    }
+  }
+}
+

# Percentiles Aggregation

Percentiles Aggregation 用于百分位统计。百分位数是一个统计学术语，如果将一组数据从大到小排序，并计算相应的累计百分位，某一百分位所对应数据的值就称为这一百分位的百分位数。默认情况下，累计百分位为 [ 1, 5, 25, 50, 75, 95, 99 ]。以下例子给出了在 latency 索引中对 load_time 字段进行加载时间的百分位统计，查询语句如下：

GET latency/_search
+{
+  "size": 0,
+  "aggs" : {
+    "load_time_outlier" : {
+      "percentiles" : {
+        "field" : "load_time"
+      }
+    }
+  }
+}
+

需要注意的是，如上的 load_time 字段必须是数字类型。

聚合结果如下：

{
+  ...
+  "aggregations": {
+    "load_time_outlier": {
+      "values" : {
+        "1.0": 5.0,
+        "5.0": 25.0,
+        "25.0": 165.0,
+        "50.0": 445.0,
+        "75.0": 725.0,
+        "95.0": 945.0,
+        "99.0": 985.0
+      }
+    }
+  }
+}
+

百分位的统计也可以指定 percents 参数指定百分位，如下：

GET latency/_search
+{
+  "size": 0,
+  "aggs" : {
+    "load_time_outlier" : {
+      "percentiles" : {
+        "field" : "load_time",
+        "percents": [60, 80, 95]
+      }
+    }
+  }
+}
+

# Percentiles Ranks Aggregation

Percentiles Ranks Aggregation 与 Percentiles Aggregation 统计恰恰相反，就是想看当前数值处在什么范围内（百分位）， 假如你查一下当前值 500 和 600 所处的百分位，发现是 90.01 和 100，那么说明有 90.01 % 的数值都在 500 以内，100 % 的数值在 600 以内。

GET latency/_search
+{
+  "size": 0,
+    "aggs" : {
+      "load_time_ranks" : {
+        "percentile_ranks" : {
+          "field" : "load_time",
+          "values" : [500, 600]
+        }
+      }
+  }
+}
+

同样 load_time 字段必须是数字类型。

返回结果大概类似如下：

{
+  ...
+  "aggregations": {
+    "load_time_ranks": {
+      "values" : {
+        "500.0": 90.01,
+        "600.0": 100.0
+      }
+    }
+  }
+}
+

可以设置 keyed 参数为 true，将对应的 values 作为桶 key 一起返回，默认是 false。

GET latency/_search
+{
+  "size": 0,
+  "aggs": {
+    "load_time_ranks": {
+      "percentile_ranks": {
+        "field": "load_time",
+        "values": [500, 600],
+        "keyed": true
+      }
+    }
+  }
+}
+

返回结果如下：

{
+  ...
+  "aggregations": {
+    "load_time_ranks": {
+      "values": [
+        {
+          "key": 500.0,
+          "value": 90.01
+        },
+        {
+          "key": 600.0,
+          "value": 100.0
+        }
+      ]
+    }
+  }
+}
+

# 桶聚合

bucket 可以理解为一个桶，它会遍历文档中的内容，凡是符合某一要求的就放入一个桶中，分桶相当于 SQL 中的 group by。从另外一个角度，可以将指标聚合看成单桶聚合，即把所有文档放到一个桶中，而桶聚合是多桶型聚合，它根据相应的条件进行分组。

种类 描述/场景
词项聚合（Terms Aggregation） 用于分组聚合，让用户得知文档中每个词项的频率，它返回每个词项出现的次数。
差异词项聚合（Significant Terms Aggregation） 它会返回某个词项在整个索引中和在查询结果中的词频差异，这有助于我们发现搜索场景中有意义的词。
过滤器聚合（Filter Aggregation） 指定过滤器匹配的所有文档到单个桶（bucket），通常这将用于将当前聚合上下文缩小到一组特定的文档。
多过滤器聚合（Filters Aggregation） 指定多个过滤器匹配所有文档到多个桶（bucket）。
范围聚合（Range Aggregation） 范围聚合，用于反映数据的分布情况。
日期范围聚合（Date Range Aggregation） 专门用于日期类型的范围聚合。
IP 范围聚合（IP Range Aggregation） 用于对 IP 类型数据范围聚合。
直方图聚合（Histogram Aggregation） 可能是数值，或者日期型，和范围聚集类似。
时间直方图聚合（Date Histogram Aggregation） 时间直方图聚合，常用于按照日期对文档进行统计并绘制条形图。
空值聚合（Missing Aggregation） 空值聚合，可以把文档集中所有缺失字段的文档分到一个桶中。
地理点范围聚合（Geo Distance Aggregation） 用于对地理点（geo point）做范围统计。

# Terms Aggregation

Terms Aggregation 用于词项的分组聚合。最为经典的用例是获取 X 中最频繁（top frequent）的项目，其中 X 是文档中的某个字段，如用户的名称、标签或分类。由于 terms 聚集统计的是每个词条，而不是整个字段值，因此通常需要在一个非分析型的字段上运行这种聚集。原因是, 你期望“big data”作为词组统计，而不是“big”单独统计一次，“data”再单独统计一次。

用户可以使用 terms 聚集，从分析型字段（如内容）中抽取最为频繁的词条。还可以使用这种信息来生成一个单词云。

{
+  "aggs": {
+    "profit_terms": {
+      "terms": { // terms 聚合 关键字
+        "field": "profit",
+        ......
+      }
+    }
+  }
+}
+

在 terms 分桶的基础上，还可以对每个桶进行指标统计，也可以基于一些指标或字段值进行排序。示例如下：

{
+  "aggs": {
+    "item_terms": {
+      "terms": {
+        "field": "item_id",
+        "size": 1000,
+        "order":[{
+          "gmv_stat": "desc"
+        },{
+          "gmv_180d": "desc"
+        }]
+      },
+      "aggs": {
+        "gmv_stat": {
+          "sum": {
+            "field": "gmv"
+          }
+        },
+        "gmv_180d": {
+          "sum": {
+            "script": "doc['gmv_90d'].value*2"
+          }
+        }
+      }
+    }
+  }
+}
+

返回的结果如下：

{
+  ...
+  "aggregations": {
+    "hospital_id_agg": {
+      "doc_count_error_upper_bound": 0,
+      "sum_other_doc_count": 260,
+      "buckets": [
+        {
+          "key": 23388,
+          "doc_count": 18,
+          "gmv_stat": {
+            "value": 176220
+          },
+          "gmv_180d": {
+            "value": 89732
+          }
+        },
+        {
+          "key": 96117,
+          "doc_count": 16,
+          "gmv_stat": {
+            "value": 129306
+          },
+          "gmv_180d": {
+            "value": 56988
+          }
+        },
+        ...
+      ]
+    }
+  }
+}
+

默认情况下返回按文档计数从高到低的前 10 个分组，可以通过 size 参数指定返回的分组数。

# Filter Aggregation

Filter Aggregation 是过滤器聚合，可以把符合过滤器中的条件的文档分到一个桶中，即是单分组聚合。

{
+  "aggs": {
+    "age_terms": {
+      "filter": {"match":{"gender":"F"}},
+      "aggs": {
+        "avg_age": {
+          "avg": {
+            "field": "age"
+          }
+        }
+      }
+    }
+  }
+}
+

# Filters Aggregation

Filters Aggregation 是多过滤器聚合，可以把符合多个过滤条件的文档分到不同的桶中，即每个分组关联一个过滤条件，并收集所有满足自身过滤条件的文档。

{
+  "size": 0,
+  "aggs": {
+    "messages": {
+      "filters": {
+        "filters": {
+          "errors": { "match": { "body": "error" } },
+          "warnings": { "match": { "body": "warning" } }
+        }
+      }
+    }
+  }
+}
+

在这个例子里，我们分析日志信息。聚合会创建两个关于日志数据的分组，一个收集包含错误信息的文档，另一个收集包含告警信息的文档。而且每个分组会按月份划分。

{
+  ...
+  "aggregations": {
+    "messages": {
+      "buckets": {
+        "errors": {
+          "doc_count": 1
+        },
+        "warnings": {
+          "doc_count": 2
+        }
+      }
+    }
+  }
+}
+

# Range Aggregation

Range Aggregation 范围聚合是一个基于多组值来源的聚合，可以让用户定义一系列范围，每个范围代表一个分组。在聚合执行的过程中，从每个文档提取出来的值都会检查每个分组的范围，并且使相关的文档落入分组中。注意，范围聚合的每个范围内包含 from 值但是排除 to 值。

{
+  "aggs": {
+    "age_range": {
+      "range": {
+        "field": "age",
+          "ranges": [{
+            "to": 25
+          },
+          {
+            "from": 25,
+            "to": 35
+          },
+          {
+            "from": 35
+          }]
+        },
+        "aggs": {
+          "bmax": {
+            "max": {
+              "field": "balance"
+            }
+          }
+        }
+      }
+    }
+  }
+}
+

返回结果如下：

{
+  ...
+  "aggregations": {
+    "age_range": {
+      "buckets": [{
+        "key": "*-25.0",
+        "to": 25,
+        "doc_count": 225,
+        "bmax": {
+          "value": 49587
+        }
+      },
+      {
+        "key": "25.0-35.0",
+        "from": 25,
+        "to": 35,
+        "doc_count": 485,
+        "bmax": {
+          "value": 49795
+        }
+      },
+      {
+        "key": "35.0-*",
+        "from": 35,
+        "doc_count": 290,
+        "bmax": {
+          "value": 49989
+        }
+      }]
+    }
+  }
+}
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#聚合
上次更新: 2023/06/29, 22:27:04
Elasticsearch 排序
Elasticsearch 分析器

+ ← + Elasticsearch 分析器→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/fc47af/index.html b/pages/fc47af/index.html new file mode 100644 index 00000000..ae326959 --- /dev/null +++ b/pages/fc47af/index.html @@ -0,0 +1,94 @@ + + + + + + Kibana 运维 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-16
目录

Kibana 运维

# Kibana 运维

通过 Kibana，您可以对自己的 Elasticsearch 进行可视化，还可以在 Elastic Stack 中进行导航，这样您便可以进行各种操作了，从跟踪查询负载，到理解请求如何流经您的整个应用，都能轻松完成。

# 1. 安装

# 1.1. 环境要求

版本：Elastic Stack 7.4

# 1.2. 安装步骤

安装步骤如下：

  1. 在 kibana 官方下载地址 (opens new window)下载所需版本包并解压到本地。
  2. 修改 config/kibana.yml 配置文件，设置 elasticsearch.url 指向 Elasticsearch 实例。
  3. 运行 bin/kibana （Windows 上运行 bin\kibana.bat）
  4. 在浏览器上访问 http://localhost:5601 (opens new window)

# 2. 使用

# 2.1. 检索

单击侧面导航栏中的 检索（Discover） ，可以显示 Kibana 的数据查询功能功能。

img

在搜索栏中，您可以输入 Elasticsearch 查询条件来搜索您的数据。您可以在 Discover 页面中浏览结果并在 Visualize 页面中创建已保存搜索条件的可视化。

当前索引模式显示在查询栏下方。索引模式确定提交查询时搜索哪些索引。要搜索一组不同的索引，请从下拉菜单中选择不同的模式。要添加索引模式（index pattern），请转至 Management/Kibana/Index Patterns 并单击 Add New。

您可以使用字段名称和您感兴趣的值构建搜索。对于数字字段，可以使用比较运算符，如大于（>），小于（<）或等于（=）。您可以将元素与逻辑运算符 AND，OR 和 NOT 链接，全部使用大写。

默认情况下，每个匹配文档都显示所有字段。要选择要显示的文档字段，请将鼠标悬停在“可用字段”列表上，然后单击要包含的每个字段旁边的添加按钮。例如，如果只添加 account_number，则显示将更改为包含五个帐号的简单列表：

img

kibana 的搜索栏遵循 query-string-syntax (opens new window) 文档中所说明的查询语义。

这里说明一些最基本的查询语义。

查询字符串会被解析为一系列的术语和运算符。一个术语可以是一个单词（如：quick、brown）或用双引号包围的短语（如"quick brown"）。

查询操作允许您自定义搜索 - 下面介绍了可用的选项。

# 2.1.1. 字段名称

正如查询字符串查询中所述，将在搜索条件中搜索 default_field，但可以在查询语法中指定其他字段：

例如：

  • 查询 status 字段中包含 active 关键字
status:active
+
  • title 字段包含 quick 或 brown 关键字。如果您省略 OR 运算符，则将使用默认运算符
title:(quick OR brown)
+title:(quick brown)
+
  • author 字段查找精确的短语 "john smith"，即精确查找。
author:"John Smith"
+
  • 任意字段 book.title，book.content 或 book.date 都包含 quick 或 brown（注意我们需要如何使用 \* 表示通配符）
book.\*:(quick brown)
+
  • title 字段包含任意非 null 值
_exists_:title
+

# 2.1.2. 通配符

ELK 提供了 ? 和 * 两个通配符。

  • ? 表示任意单个字符；
  • * 表示任意零个或多个字符。
qu?ck bro*
+

注意：通配符查询会使用大量的内存并且执行性能较为糟糕，所以请慎用。 > 提示：纯通配符 * 被写入 exsits (opens new window) 查询，从而提高了查询效率。因此，通配符 field：* 将匹配包含空值的文档，如：{“field”：“”}，但是如果字段丢失或显示将值置为 null 则不匹配，如：“field”：null} > 提示：在一个单词的开头（例如：*ing）使用通配符这种方式的查询量特别大，因为索引中的所有术语都需要检查，以防万一匹配。通过将 allow_leading_wildcard 设置为 false，可以禁用。

# 2.1.3. 正则表达式

可以通过 / 将正则表达式包裹在查询字符串中进行查询

例：

name:/joh?n(ath[oa]n)/
+

支持的正则表达式语义可以参考：Regular expression syntax (opens new window)

# 2.1.4. 模糊查询

我们可以使用 ~ 运算符来进行模糊查询。

例：

假设我们实际想查询

quick brown forks
+

但是，由于拼写错误，我们的查询关键字变成如下情况，依然可以查到想要的结果。

quikc\~ brwn\~ foks\~
+

这种模糊查询使用 Damerau-Levenshtein 距离来查找所有匹配最多两个更改的项。所谓的更改是指单个字符的插入，删除或替换，或者两个相邻字符的换位。

默认编辑距离为 2，但编辑距离为 1 应足以捕捉所有人类拼写错误的 80％。它可以被指定为：

quikc\~1
+

# 2.1.5. 近似检索

尽管短语查询（例如，john smith）期望所有的词条都是完全相同的顺序，但是近似查询允许指定的单词进一步分开或以不同的顺序排列。与模糊查询可以为单词中的字符指定最大编辑距离一样，近似搜索也允许我们指定短语中单词的最大编辑距离：

例

"fox quick"\~5
+

字段中的文本越接近查询字符串中指定的原始顺序，该文档就越被认为是相关的。当与上面的示例查询相比时，短语 "quick fox" 将被认为比 "quick brown fox" 更近似查询条件。

# 2.1.6. 范围

可以为日期，数字或字符串字段指定范围。闭区间范围用方括号 [min TO max] 和开区间范围用花括号 {min TO max} 来指定。

我们不妨来看一些示例。

  • 2012 年的所有日子
date:[2012-01-01 TO 2012-12-31]
+
  • 数字 1 到 5
count:[1 TO 5]
+
  • 在 alpha 和 omega 之间的标签，不包括 alpha 和 omega
tag:{alpha TO omega}
+
  • 10 以上的数字
count:[10 TO *]
+
  • 2012 年以前的所有日期
date:{* TO 2012-01-01}
+

此外，开区间和闭区间也可以组合使用

  • 数组 1 到 5，但不包括 5
count:[1 TO 5}
+

一边无界的范围也可以使用以下语法：

age:>10
+age:>=10
+age:<10
+age:<=10
+

当然，你也可以使用 AND 运算符来得到连个查询结果的交集

age:(>=10 AND <20)
+age:(+>=10 +<20)
+

# 2.1.7. Boosting

使用操作符 ^ 使一个术语比另一个术语更相关。例如，如果我们想查找所有有关狐狸的文档，但我们对狐狸特别感兴趣：

quick^2 fox
+

默认提升值是 1，但可以是任何正浮点数。 0 到 1 之间的提升减少了相关性。

增强也可以应用于短语或组：

"john smith"^2   (foo bar)^4
+

# 2.1.8. 布尔操作

默认情况下，只要一个词匹配，所有词都是可选的。搜索 foo bar baz 将查找包含 foo 或 bar 或 baz 中的一个或多个的任何文档。我们已经讨论了上面的default_operator，它允许你强制要求所有的项，但也有布尔运算符可以在查询字符串本身中使用，以提供更多的控制。

首选的操作符是 +（此术语必须存在）和 - （此术语不得存在）。所有其他条款是可选的。例如，这个查询：

quick brown +fox -news
+

这条查询意味着：

  • fox 必须存在
  • news 必须不存在
  • quick 和 brown 是可有可无的

熟悉的运算符 AND，OR 和 NOT（也写成 &&，|| 和 !）也被支持。然而，这些操作符有一定的优先级：NOT 优先于 AND，AND 优先于 OR。虽然 + 和 - 仅影响运算符右侧的术语，但 AND 和 OR 会影响左侧和右侧的术语。

# 2.1.9. 分组

多个术语或子句可以用圆括号组合在一起，形成子查询

(quick OR brown) AND fox
+

可以使用组来定位特定的字段，或者增强子查询的结果：

status:(active OR pending) title:(full text search)^2
+

# 2.1.10. 保留字

如果你需要使用任何在你的查询本身中作为操作符的字符（而不是作为操作符），那么你应该用一个反斜杠来转义它们。例如，要搜索（1 + 1）= 2，您需要将查询写为 \(1\+1\)\=2

保留字符是：+ - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /

无法正确地转义这些特殊字符可能会导致语法错误，从而阻止您的查询运行。

# 2.1.11. 空查询

如果查询字符串为空或仅包含空格，则查询将生成一个空的结果集。

# 2.2. 可视化

要想使用可视化的方式展示您的数据，请单击侧面导航栏中的 可视化（Visualize）。

Visualize 工具使您能够以多种方式（如饼图、柱状图、曲线图、分布图等）查看数据。要开始使用，请点击蓝色的 Create a visualization 或 + 按钮。

https://www.elastic.co/guide/en/kibana/6.1/images/tutorial-visualize-landing.png

有许多可视化类型可供选择。

https://www.elastic.co/guide/en/kibana/6.1/images/tutorial-visualize-wizard-step-1.png

下面，我们来看创建几个图标示例：

# 2.2.1. Pie

您可以从保存的搜索中构建可视化文件，也可以输入新的搜索条件。要输入新的搜索条件，首先需要选择一个索引模式来指定要搜索的索引。

默认搜索匹配所有文档。最初，一个“切片”包含整个饼图：

https://www.elastic.co/guide/en/kibana/6.1/images/tutorial-visualize-pie-1.png

要指定在图表中展示哪些数据，请使用 Elasticsearch 存储桶聚合。分组汇总只是将与您的搜索条件相匹配的文档分类到不同的分类中，也称为分组。

为每个范围定义一个存储桶：

  1. 单击 Split Slices。
  2. 在 Aggregation 列表中选择 Terms。注意：这里的 Terms 是 Elk 采集数据时定义好的字段或标签。
  3. 在 Field 列表中选择 level.keyword。
  4. 点击 images/apply-changes-button.png 按钮来更新图表。

image.png

完成后，如果想要保存这个图表，可以点击页面最上方一栏中的 Save 按钮。

# 2.2.2. Vertical Bar

我们在展示一下如何创建柱状图。

  1. 点击蓝色的 Create a visualization 或 + 按钮。选择 Vertical Bar
  2. 选择索引模式。由于您尚未定义任何 bucket ，因此您会看到一个大栏，显示与默认通配符查询匹配的文档总数。
  3. 指定 Y 轴所代表的字段
  4. 指定 X 轴所代表的字段
  5. 点击 images/apply-changes-button.png 按钮来更新图表。

image.png

完成后，如果想要保存这个图表，可以点击页面最上方一栏中的 Save 按钮。

# 2.3. 报表

报表（Dashboard） 可以整合和共享 Visualize 集合。

  1. 点击侧面导航栏中的 Dashboard。
  2. 点击添加显示保存的可视化列表。
  3. 点击之前保存的 Visualize，然后点击列表底部的小向上箭头关闭可视化列表。
  4. 将鼠标悬停在可视化对象上会显示允许您编辑，移动，删除和调整可视化对象大小的容器控件。

# 3. FAQ

# 3.1. Kibana No Default Index Pattern Warning

**问题：**安装 ELK 后，访问 kibana 页面时，提示以下错误信息：

Warning No default index pattern. You must select or create one to continue.
+...
+Unable to fetch mapping. Do you have indices matching the pattern?
+

这就说明 logstash 没有把日志写入到 elasticsearch。

解决方法：

检查 logstash 与 elasticsearch 之间的通讯是否有问题，一般问题就出在这。

# 4. 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elastic#Kibana
上次更新: 2023/06/29, 22:27:04
Elastic 技术栈之 Kibana
Elastic 技术栈之 Logstash

+ ← + Elastic 技术栈之 Logstash→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/fcb19c/index.html b/pages/fcb19c/index.html new file mode 100644 index 00000000..e0868f13 --- /dev/null +++ b/pages/fcb19c/index.html @@ -0,0 +1,119 @@ + + + + + + Mysql 索引 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-07-16
目录

Mysql 索引

# Mysql 索引

索引是提高 MySQL 查询性能的一个重要途径，但过多的索引可能会导致过高的磁盘使用率以及过高的内存占用，从而影响应用程序的整体性能。应当尽量避免事后才想起添加索引，因为事后可能需要监控大量的 SQL 才能定位到问题所在，而且添加索引的时间肯定是远大于初始添加索引所需要的时间，可见索引的添加也是非常有技术含量的。

接下来将向你展示一系列创建高性能索引的策略，以及每条策略其背后的工作原理。但在此之前，先了解与索引相关的一些算法和数据结构，将有助于更好的理解后文的内容。

img

# 索引简介

索引是数据库为了提高查找效率的一种数据结构。

索引对于良好的性能非常关键，在数据量小且负载较低时，不恰当的索引对于性能的影响可能还不明显；但随着数据量逐渐增大，性能则会急剧下降。因此，索引优化应该是查询性能优化的最有效手段。

# 索引的优缺点

B 树是最常见的索引，按照顺序存储数据，所以 Mysql 可以用来做 ORDER BY 和 GROUP BY 操作。因为数据是有序的，所以 B 树也就会将相关的列值都存储在一起。最后，因为索引中存储了实际的列值，所以某些查询只使用索引就能够完成全部查询。

✔ 索引的优点：

  • 索引大大减少了服务器需要扫描的数据量，从而加快检索速度。
  • 索引可以帮助服务器避免排序和临时表。
  • 索引可以将随机 I/O 变为顺序 I/O。
  • 支持行级锁的数据库，如 InnoDB 会在访问行的时候加锁。使用索引可以减少访问的行数，从而减少锁的竞争，提高并发。
  • 唯一索引可以确保每一行数据的唯一性，通过使用索引，可以在查询的过程中使用优化隐藏器，提高系统的性能。

❌ 索引的缺点：

  • 创建和维护索引要耗费时间，这会随着数据量的增加而增加。
  • 索引需要占用额外的物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立组合索引那么需要的空间就会更大。
  • 写操作（INSERT/UPDATE/DELETE）时很可能需要更新索引，导致数据库的写操作性能降低。

# 何时使用索引

索引能够轻易将查询性能提升几个数量级。

✔ 什么情况适用索引：

  • 频繁读操作（ SELECT ）
  • 表的数据量比较大。
  • 列名经常出现在 WHERE 或连接（JOIN）条件中。

❌ 什么情况不适用索引：

  • 频繁写操作（ INSERT/UPDATE/DELETE ），也就意味着需要更新索引。
  • 列名不经常出现在 WHERE 或连接（JOIN）条件中，也就意味着索引会经常无法命中，没有意义，还增加空间开销。
  • 非常小的表，对于非常小的表，大部分情况下简单的全表扫描更高效。
  • 特大型的表，建立和使用索引的代价将随之增长。可以考虑使用分区技术或 Nosql。

# 索引的数据结构

在 Mysql 中，索引是在存储引擎层而不是服务器层实现的。所以，并没有统一的索引标准；不同存储引擎的索引的数据结构也不相同。

# 数组

数组是用连续的内存空间来存储数据，并且支持随机访问。

有序数组可以使用二分查找法，其时间复杂度为 O(log n)，无论是等值查询还是范围查询，都非常高效。

但数组有两个重要限制：

  • 数组的空间大小固定，如果要扩容只能采用复制数组的方式。
  • 插入、删除时间复杂度为 O(n)。

这意味着，如果使用数组作为索引，如果要保证数组有序，其更新操作代价高昂。

# 哈希索引

哈希表是一种以键 - 值（key-value）对形式存储数据的结构，我们只要输入待查找的值即 key，就可以找到其对应的值即 Value。

哈希表 使用 哈希函数 组织数据，以支持快速插入和搜索的数据结构。哈希表的本质是一个数组，其思路是：使用 Hash 函数将 Key 转换为数组下标，利用数组的随机访问特性，使得我们能在 O(1) 的时间代价内完成检索。

img

有两种不同类型的哈希表：哈希集合 和 哈希映射。

  • 哈希集合 是集合数据结构的实现之一，用于存储非重复值。
  • 哈希映射 是映射 数据结构的实现之一，用于存储键值对。

哈希索引基于哈希表实现，只适用于等值查询。对于每一行数据，哈希索引都会将所有的索引列计算一个哈希码（hashcode），哈希码是一个较小的值。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针。

在 Mysql 中，只有 Memory 存储引擎显示支持哈希索引。

✔ 哈希索引的优点：

  • 因为索引数据结构紧凑，所以查询速度非常快。

❌ 哈希索引的缺点：

  • 哈希索引值包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，所以大部分情况下这一点对性能影响不大。
  • 哈希索引数据不是按照索引值顺序存储的，所以无法用于排序。
  • 哈希索引不支持部分索引匹配查找，因为哈希索引时使用索引列的全部内容来进行哈希计算的。如，在数据列 (A,B) 上建立哈希索引，如果查询只有数据列 A，无法使用该索引。
  • 哈希索引只支持等值比较查询，包括 =、IN()、<=>；不支持任何范围查询，如 WHERE price > 100。
  • 哈希索引有可能出现哈希冲突
    • 出现哈希冲突时，必须遍历链表中所有的行指针，逐行比较，直到找到符合条件的行。
    • 如果哈希冲突多的话，维护索引的代价会很高。

因为种种限制，所以哈希索引只适用于特定的场合。而一旦使用哈希索引，则它带来的性能提升会非常显著。

# B 树索引

通常我们所说的索引是指B-Tree索引，它是目前关系型数据库中查找数据最为常用和有效的索引，大多数存储引擎都支持这种索引。使用B-Tree这个术语，是因为 MySQL 在CREATE TABLE或其它语句中使用了这个关键字，但实际上不同的存储引擎可能使用不同的数据结构，比如 InnoDB 就是使用的B+Tree。

B+Tree中的 B 是指balance，意为平衡。需要注意的是，B+树索引并不能找到一个给定键值的具体行，它找到的只是被查找数据行所在的页，接着数据库会把页读入到内存，再在内存中进行查找，最后得到要查找的数据。

# 二叉搜索树

二叉搜索树的特点是：每个节点的左儿子小于父节点，父节点又小于右儿子。其查询时间复杂度是 $$O(log(N))$$。

当然为了维持 $$O(log(N))$$ 的查询复杂度，你就需要保持这棵树是平衡二叉树。为了做这个保证，更新的时间复杂度也是 $$O(log(N))$$。

随着数据库中数据的增加，索引本身大小随之增加，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。这样的话，索引查找过程中就要产生磁盘 I/O 消耗，相对于内存存取，I/O 存取的消耗要高几个数量级。可以想象一下一棵几百万节点的二叉树的深度是多少？如果将这么大深度的一颗二叉树放磁盘上，每读取一个节点，需要一次磁盘的 I/O 读取，整个查找的耗时显然是不能够接受的。那么如何减少查找过程中的 I/O 存取次数？

一种行之有效的解决方法是减少树的深度，将二叉树变为 N 叉树（多路搜索树），而 B+ 树就是一种多路搜索树。

# B+ 树

B+ 树索引适用于全键值查找、键值范围查找和键前缀查找，其中键前缀查找只适用于最左前缀查找。

理解B+Tree时，只需要理解其最重要的两个特征即可：

  • 第一，所有的关键字（可以理解为数据）都存储在叶子节点，非叶子节点并不存储真正的数据，所有记录节点都是按键值大小顺序存放在同一层叶子节点上。
  • 其次，所有的叶子节点由指针连接。如下图为简化了的B+Tree。

img

根据叶子节点的内容，索引类型分为主键索引和非主键索引。

  • 聚簇索引（clustered）：又称为主键索引，其叶子节点存的是整行数据。因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。InnoDB 的聚簇索引实际是在同一个结构中保存了 B 树的索引和数据行。
  • 非主键索引的叶子节点内容是主键的值。在 InnoDB 里，非主键索引也被称为二级索引（secondary）。数据存储在一个位置，索引存储在另一个位置，索引中包含指向数据存储位置的指针。可以有多个，小于 249 个。

聚簇表示数据行和相邻的键值紧凑地存储在一起，因为数据紧凑，所以访问快。因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。

聚簇索引和非聚簇索引的查询有什么区别

  • 如果语句是 select * from T where ID=500，即聚簇索引查询方式，则只需要搜索 ID 这棵 B+ 树；
  • 如果语句是 select * from T where k=5，即非聚簇索引查询方式，则需要先搜索 k 索引树，得到 ID 的值为 500，再到 ID 索引树搜索一次。这个过程称为回表。

也就是说，基于非聚簇索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。

显然，主键长度越小，非聚簇索引的叶子节点就越小，非聚簇索引占用的空间也就越小。

自增主键是指自增列上定义的主键，在建表语句中一般是这么定义的： NOT NULL PRIMARY KEY AUTO_INCREMENT。从性能和存储空间方面考量，自增主键往往是更合理的选择。有没有什么场景适合用业务字段直接做主键的呢？还是有的。比如，有些业务的场景需求是这样的：

  • 只有一个索引；
  • 该索引必须是唯一索引。

由于没有其他索引，所以也就不用考虑其他索引的叶子节点大小的问题。

这时候我们就要优先考虑上一段提到的“尽量使用主键查询”原则，直接将这个索引设置为主键，可以避免每次查询需要搜索两棵树。

# 全文索引

MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而不是直接比较是否相等。查找条件使用 MATCH AGAINST，而不是普通的 WHERE。

全文索引一般使用倒排索引实现，它记录着关键词到其所在文档的映射。

InnoDB 存储引擎在 MySQL 5.6.4 版本中也开始支持全文索引。

# 空间数据索引

MyISAM 存储引擎支持空间数据索引（R-Tree），可以用于地理数据存储。空间数据索引会从所有维度来索引数据，可以有效地使用任意维度来进行组合查询。

必须使用 GIS 相关的函数来维护数据。

# 索引的类型

主流的关系型数据库一般都支持以下索引类型：

# 主键索引（PRIMARY）

主键索引：一种特殊的唯一索引，不允许有空值。一个表只能有一个主键（在 InnoDB 中本质上即聚簇索引），一般是在建表的时候同时创建主键索引。

CREATE TABLE `table` (
+    `id` int(11) NOT NULL AUTO_INCREMENT,
+    ...
+    PRIMARY KEY (`id`)
+)
+

# 唯一索引（UNIQUE）

唯一索引：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。

CREATE TABLE `table` (
+    ...
+    UNIQUE indexName (title(length))
+)
+

# 普通索引（INDEX）

普通索引：最基本的索引，没有任何限制。

CREATE TABLE `table` (
+    ...
+    INDEX index_name (title(length))
+)
+

# 全文索引（FULLTEXT）

全文索引：主要用来查找文本中的关键字，而不是直接与索引中的值相比较。

全文索引跟其它索引大不相同，它更像是一个搜索引擎，而不是简单的 WHERE 语句的参数匹配。全文索引配合 match against 操作使用，而不是一般的 WHERE 语句加 LIKE。它可以在 CREATE TABLE，ALTER TABLE ，CREATE INDEX 使用，不过目前只有 char、varchar，text 列上可以创建全文索引。值得一提的是，在数据量较大时候，现将数据放入一个没有全局索引的表中，然后再用 CREATE INDEX 创建全文索引，要比先为一张表建立全文索引然后再将数据写入的速度快很多。

CREATE TABLE `table` (
+    `content` text CHARACTER NULL,
+    ...
+    FULLTEXT (content)
+)
+

# 联合索引

组合索引：多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循最左前缀集合。

CREATE TABLE `table` (
+    ...
+    INDEX index_name (title(length), title(length), ...)
+)
+

# 索引的策略

假设有以下表：

CREATE TABLE `t` (
+  `id` int(11) NOT NULL,
+  `city` varchar(16) NOT NULL,
+  `name` varchar(16) NOT NULL,
+  `age` int(11) NOT NULL,
+  `addr` varchar(128) DEFAULT NULL,
+  PRIMARY KEY (`id`),
+  KEY `city` (`city`)
+) ENGINE=InnoDB;
+

# 索引基本原则

  • 索引不是越多越好，不要为所有列都创建索引。要考虑到索引的维护代价、空间占用和查询时回表的代价。索引一定是按需创建的，并且要尽可能确保足够轻量。一旦创建了多字段的联合索引，我们要考虑尽可能利用索引本身完成数据查询，减少回表的成本。
  • 要尽量避免冗余和重复索引。
  • 要考虑删除未使用的索引。
  • 尽量的扩展索引，不要新建索引。
  • 频繁作为 WHERE 过滤条件的列应该考虑添加索引。

# 独立的列

“独立的列” 是指索引列不能是表达式的一部分，也不能是函数的参数。

对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。

如果查询中的列不是独立的列，则数据库不会使用索引。

❌ 错误示例：

SELECT actor_id FROM actor WHERE actor_id + 1 = 5;
+SELECT ... WHERE TO_DAYS(current_date) - TO_DAYS(date_col) <= 10;
+

# 覆盖索引

覆盖索引是指，索引上的信息足够满足查询请求，不需要回表查询数据。

【示例】范围查询

create table T (
+ID int primary key,
+k int NOT NULL DEFAULT 0,
+s varchar(16) NOT NULL DEFAULT '',
+index k(k))
+engine=InnoDB;
+
+insert into T values(100,1, 'aa'),(200,2,'bb'),(300,3,'cc'),(500,5,'ee'),(600,6,'ff'),(700,7,'gg');
+
+select * from T where k between 3 and 5
+

需要执行几次树的搜索操作，会扫描多少行？

  1. 在 k 索引树上找到 k=3 的记录，取得 ID = 300；
  2. 再到 ID 索引树查到 ID=300 对应的 R3；
  3. 在 k 索引树取下一个值 k=5，取得 ID=500；
  4. 再回到 ID 索引树查到 ID=500 对应的 R4；
  5. 在 k 索引树取下一个值 k=6，不满足条件，循环结束。

在这个过程中，回到主键索引树搜索的过程，我们称为回表。可以看到，这个查询过程读了 k 索引树的 3 条记录（步骤 1、3 和 5），回表了两次（步骤 2 和 4）。

如果执行的语句是 select ID from T where k between 3 and 5，这时只需要查 ID 的值，而 ID 的值已经在 k 索引树上了，因此可以直接提供查询结果，不需要回表。索引包含所有需要查询的字段的值，称为覆盖索引。

由于覆盖索引可以减少树的搜索次数，显著提升查询性能，所以使用覆盖索引是一个常用的性能优化手段。

# 使用索引来排序

Mysql 有两种方式可以生成排序结果：通过排序操作；或者按索引顺序扫描。

索引最好既满足排序，又用于查找行。这样，就可以通过命中覆盖索引直接将结果查出来，也就不再需要排序了。

这样整个查询语句的执行流程就变成了：

  1. 从索引 (city,name,age) 找到第一个满足 city='杭州’条件的记录，取出其中的 city、name 和 age 这三个字段的值，作为结果集的一部分直接返回；
  2. 从索引 (city,name,age) 取下一个记录，同样取出这三个字段的值，作为结果集的一部分直接返回；
  3. 重复执行步骤 2，直到查到第 1000 条记录，或者是不满足 city='杭州’条件时循环结束。

# 前缀索引

有时候需要索引很长的字符列，这会让索引变得大且慢。

这时，可以使用前缀索引，即只索引开始的部分字符，这样可以大大节约索引空间，从而提高索引效率。但这样也会降低索引的选择性。对于 BLOB/TEXT/VARCHAR 这种文本类型的列，必须使用前缀索引，因为数据库往往不允许索引这些列的完整长度。

索引的选择性是指：不重复的索引值和数据表记录总数的比值。最大值为 1，此时每个记录都有唯一的索引与其对应。选择性越高，查询效率也越高。如果存在多条命中前缀索引的情况，就需要依次扫描，直到最终找到正确记录。

使用前缀索引，定义好长度，就可以做到既节省空间，又不用额外增加太多的查询成本。

那么，如何确定前缀索引合适的长度呢？

可以使用下面这个语句，算出这个列上有多少个不同的值：

select count(distinct email) as L from SUser;
+

然后，依次选取不同长度的前缀来看这个值，比如我们要看一下 4~7 个字节的前缀索引，可以用这个语句：

select
+  count(distinct left(email,4)）as L4,
+  count(distinct left(email,5)）as L5,
+  count(distinct left(email,6)）as L6,
+  count(distinct left(email,7)）as L7,
+from SUser;
+

当然，使用前缀索引很可能会损失区分度，所以你需要预先设定一个可以接受的损失比例，比如 5%。然后，在返回的 L4~L7 中，找出不小于 L * 95% 的值，假设这里 L6、L7 都满足，你就可以选择前缀长度为 6。

此外，order by 无法使用前缀索引，无法把前缀索引用作覆盖索引。

# 最左前缀匹配原则

不只是索引的全部定义，只要满足最左前缀，就可以利用索引来加速检索。这个最左前缀可以是联合索引的最左 N 个字段，也可以是字符串索引的最左 M 个字符。

MySQL 会一直向右匹配直到遇到范围查询 (>,<,BETWEEN,LIKE) 就停止匹配。

  • 索引可以简单如一个列(a)，也可以复杂如多个列(a, b, c, d)，即联合索引。
  • 如果是联合索引，那么 key 也由多个列组成，同时，索引只能用于查找 key 是否存在（相等），遇到范围查询(>、<、between、like 左匹配)等就不能进一步匹配了，后续退化为线性查找。
  • 因此，列的排列顺序决定了可命中索引的列数。

不要为每个列都创建独立索引。

将选择性高的列或基数大的列优先排在多列索引最前列。但有时，也需要考虑 WHERE 子句中的排序、分组和范围条件等因素，这些因素也会对查询性能造成较大影响。

例如：a = 1 and b = 2 and c > 3 and d = 4，如果建立（a,b,c,d）顺序的索引，d 是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d 的顺序可以任意调整。

让选择性最强的索引列放在前面，索引的选择性是指：不重复的索引值和记录总数的比值。最大值为 1，此时每个记录都有唯一的索引与其对应。选择性越高，查询效率也越高。

例如下面显示的结果中 customer_id 的选择性比 staff_id 更高，因此最好把 customer_id 列放在多列索引的前面。

SELECT COUNT(DISTINCT staff_id)/COUNT(*) AS staff_id_selectivity,
+COUNT(DISTINCT customer_id)/COUNT(*) AS customer_id_selectivity,
+COUNT(*)
+FROM payment;
+
   staff_id_selectivity: 0.0001
+customer_id_selectivity: 0.0373
+               COUNT(*): 16049
+

# = 和 in 可以乱序

不需要考虑 =、IN 等的顺序，Mysql 会自动优化这些条件的顺序，以匹配尽可能多的索引列。

【示例】如有索引 (a, b, c, d)，查询条件 c > 3 and b = 2 and a = 1 and d < 4 与 a = 1 and c > 3 and b = 2 and d < 4 等顺序都是可以的，MySQL 会自动优化为 a = 1 and b = 2 and c > 3 and d < 4，依次命中 a、b、c、d。

# 索引最佳实践

创建了索引，并非一定有效。比如不满足前缀索引、最左前缀匹配原则、查询条件涉及函数计算等情况都无法使用索引。此外，即使 SQL 本身符合索引的使用条件，MySQL 也会通过评估各种查询方式的代价，来决定是否走索引，以及走哪个索引。

因此，在尝试通过索引进行 SQL 性能优化的时候，务必通过执行计划（EXPLAIN）或实际的效果来确认索引是否能有效改善性能问题，否则增加了索引不但没解决性能问题，还增加了数据库增删改的负担。如果对 EXPLAIN 给出的执行计划有疑问的话，你还可以利用 optimizer_trace 查看详细的执行计划做进一步分析。

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#关系型数据库#Mysql#索引
上次更新: 2023/06/29, 22:27:04
Mysql 锁
Mysql 性能优化

+ ← + Mysql 性能优化→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/fdaf15/index.html b/pages/fdaf15/index.html new file mode 100644 index 00000000..94d7685e --- /dev/null +++ b/pages/fdaf15/index.html @@ -0,0 +1,146 @@ + + + + + + Elasticsearch 运维 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-06-16
目录

Elasticsearch 运维

# Elasticsearch 运维

Elasticsearch (opens new window) 是一个分布式、RESTful 风格的搜索和数据分析引擎，能够解决不断涌现出的各种用例。 作为 Elastic Stack 的核心，它集中存储您的数据，帮助您发现意料之中以及意料之外的情况。

# Elasticsearch 安装

Elasticsearch 官方下载安装说明 (opens new window)

（1）下载解压

访问 官方下载地址 (opens new window) ，选择需要的版本，下载解压到本地。

（2）运行

运行 bin/elasticsearch (Windows 系统上运行 bin\elasticsearch.bat )

（3）访问

执行 curl http://localhost:9200/ 测试服务是否启动

# Elasticsearch 集群规划

ElasticSearch 集群需要根据业务实际情况去合理规划。

需要考虑的问题点：

  • 集群部署几个节点？
  • 有多少个索引？
  • 每个索引有多大数据量？
  • 每个索引有多少个分片？

一个参考规划：

  • 3 台机器，每台机器是 6 核 64G 的。
  • 我们 es 集群的日增量数据大概是 2000 万条，每天日增量数据大概是 500MB，每月增量数据大概是 6 亿，15G。目前系统已经运行了几个月，现在 es 集群里数据总量大概是 100G 左右。
  • 目前线上有 5 个索引（这个结合你们自己业务来，看看自己有哪些数据可以放 es 的），每个索引的数据量大概是 20G，所以这个数据量之内，我们每个索引分配的是 8 个 shard，比默认的 5 个 shard 多了 3 个 shard。

# Elasticsearch 配置

ES 的默认配置文件为 config/elasticsearch.yml

基本配置说明如下：

cluster.name: elasticsearch
+#配置es的集群名称，默认是elasticsearch，es会自动发现在同一网段下的es，如果在同一网段下有多个集群，就可以用这个属性来区分不同的集群。
+node.name: 'Franz Kafka'
+#节点名，默认随机指定一个name列表中名字，该列表在es的jar包中config文件夹里name.txt文件中，其中有很多作者添加的有趣名字。
+node.master: true
+#指定该节点是否有资格被选举成为node，默认是true，es是默认集群中的第一台机器为master，如果这台机挂了就会重新选举master。
+node.data: true
+#指定该节点是否存储索引数据，默认为true。
+index.number_of_shards: 5
+#设置默认索引分片个数，默认为5片。
+index.number_of_replicas: 1
+#设置默认索引副本个数，默认为1个副本。
+path.conf: /path/to/conf
+#设置配置文件的存储路径，默认是es根目录下的config文件夹。
+path.data: /path/to/data
+#设置索引数据的存储路径，默认是es根目录下的data文件夹，可以设置多个存储路径，用逗号隔开，例：
+#path.data: /path/to/data1,/path/to/data2
+path.work: /path/to/work
+#设置临时文件的存储路径，默认是es根目录下的work文件夹。
+path.logs: /path/to/logs
+#设置日志文件的存储路径，默认是es根目录下的logs文件夹
+path.plugins: /path/to/plugins
+#设置插件的存放路径，默认是es根目录下的plugins文件夹
+bootstrap.mlockall: true
+#设置为true来锁住内存。因为当jvm开始swapping时es的效率会降低，所以要保证它不swap，可以把#ES_MIN_MEM和ES_MAX_MEM两个环境变量设置成同一个值，并且保证机器有足够的内存分配给es。同时也要#允许elasticsearch的进程可以锁住内存，linux下可以通过`ulimit -l unlimited`命令。
+network.bind_host: 192.168.0.1
+#设置绑定的ip地址，可以是ipv4或ipv6的，默认为0.0.0.0。
+network.publish_host: 192.168.0.1
+#设置其它节点和该节点交互的ip地址，如果不设置它会自动判断，值必须是个真实的ip地址。
+network.host: 192.168.0.1
+#这个参数是用来同时设置bind_host和publish_host上面两个参数。
+transport.tcp.port: 9300
+#设置节点间交互的tcp端口，默认是9300。
+transport.tcp.compress: true
+#设置是否压缩tcp传输时的数据，默认为false，不压缩。
+http.port: 9200
+#设置对外服务的http端口，默认为9200。
+http.max_content_length: 100mb
+#设置内容的最大容量，默认100mb
+http.enabled: false
+#是否使用http协议对外提供服务，默认为true，开启。
+gateway.type: local
+#gateway的类型，默认为local即为本地文件系统，可以设置为本地文件系统，分布式文件系统，hadoop的#HDFS，和amazon的s3服务器，其它文件系统的设置方法下次再详细说。
+gateway.recover_after_nodes: 1
+#设置集群中N个节点启动时进行数据恢复，默认为1。
+gateway.recover_after_time: 5m
+#设置初始化数据恢复进程的超时时间，默认是5分钟。
+gateway.expected_nodes: 2
+#设置这个集群中节点的数量，默认为2，一旦这N个节点启动，就会立即进行数据恢复。
+cluster.routing.allocation.node_initial_primaries_recoveries: 4
+#初始化数据恢复时，并发恢复线程的个数，默认为4。
+cluster.routing.allocation.node_concurrent_recoveries: 2
+#添加删除节点或负载均衡时并发恢复线程的个数，默认为4。
+indices.recovery.max_size_per_sec: 0
+#设置数据恢复时限制的带宽，如入100mb，默认为0，即无限制。
+indices.recovery.concurrent_streams: 5
+#设置这个参数来限制从其它分片恢复数据时最大同时打开并发流的个数，默认为5。
+discovery.zen.minimum_master_nodes: 1
+#设置这个参数来保证集群中的节点可以知道其它N个有master资格的节点。默认为1，对于大的集群来说，可以设置大一点的值（2-4）
+discovery.zen.ping.timeout: 3s
+#设置集群中自动发现其它节点时ping连接超时时间，默认为3秒，对于比较差的网络环境可以高点的值来防止自动发现时出错。
+discovery.zen.ping.multicast.enabled: false
+#设置是否打开多播发现节点，默认是true。
+discovery.zen.ping.unicast.hosts: ['host1', 'host2:port', 'host3[portX-portY]']
+#设置集群中master节点的初始列表，可以通过这些节点来自动发现新加入集群的节点。
+

# Elasticsearch FAQ

# elasticsearch 不允许以 root 权限来运行

**问题：**在 Linux 环境中，elasticsearch 不允许以 root 权限来运行。

如果以 root 身份运行 elasticsearch，会提示这样的错误：

can not run elasticsearch as root
+

**解决方法：**使用非 root 权限账号运行 elasticsearch

# 创建用户组
+groupadd elk
+# 创建新用户，-g elk 设置其用户组为 elk，-p elk 设置其密码为 elk
+useradd elk -g elk -p elk
+# 更改 /opt 文件夹及内部文件的所属用户及组为 elk:elk
+chown -R elk:elk /opt # 假设你的 elasticsearch 安装在 opt 目录下
+# 切换账号
+su elk
+

# vm.max_map_count 不低于 262144

问题：vm.max_map_count 表示虚拟内存大小，它是一个内核参数。elasticsearch 默认要求 vm.max_map_count 不低于 262144。

max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
+

解决方法：

你可以执行以下命令，设置 vm.max_map_count ，但是重启后又会恢复为原值。

sysctl -w vm.max_map_count=262144
+

持久性的做法是在 /etc/sysctl.conf 文件中修改 vm.max_map_count 参数：

echo "vm.max_map_count=262144" > /etc/sysctl.conf
+sysctl -p
+

注意

如果运行环境为 docker 容器，可能会限制执行 sysctl 来修改内核参数。

这种情况下，你只能选择直接修改宿主机上的参数了。

# nofile 不低于 65536

问题： nofile 表示进程允许打开的最大文件数。elasticsearch 进程要求可以打开的最大文件数不低于 65536。

max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]
+

解决方法：

在 /etc/security/limits.conf 文件中修改 nofile 参数：

echo "* soft nofile 65536" > /etc/security/limits.conf
+echo "* hard nofile 131072" > /etc/security/limits.conf
+

# nproc 不低于 2048

问题： nproc 表示最大线程数。elasticsearch 要求最大线程数不低于 2048。

max number of threads [1024] for user [user] is too low, increase to at least [2048]
+

解决方法：

在 /etc/security/limits.conf 文件中修改 nproc 参数：

echo "* soft nproc 2048" > /etc/security/limits.conf
+echo "* hard nproc 4096" > /etc/security/limits.conf
+

# 参考资料

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#搜索引擎数据库#Elasticsearch#运维
上次更新: 2023/06/29, 22:27:04
Elasticsearch 集群和分片
Elastic 快速入门

+ ← + Elastic 快速入门→ +

最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/pages/fe3808/index.html b/pages/fe3808/index.html new file mode 100644 index 00000000..5b0184ad --- /dev/null +++ b/pages/fe3808/index.html @@ -0,0 +1,59 @@ + + + + + + Redis 教程 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
dunwu
2020-02-10
目录

Redis 教程

# Redis 教程

Redis 最典型的应用场景是作为分布式缓存。

学习 Redis，有必要深入理解缓存的原理，以及 Redis 作为一种缓存方案，在系统应用中的定位。

参考：缓存基本原理 (opens new window)，有助于理解缓存的特性、原理，使用缓存常见的问题及解决方案。

# 📖 内容

# Redis 面试总结 💯

# Redis 应用指南 ⚡

关键词：内存淘汰、事件、事务、管道、发布与订阅

img

# Redis 数据类型和应用

关键词：STRING、HASH、LIST、SET、ZSET、BitMap、HyperLogLog、Geo

Redis 数据类型

# Redis 持久化

关键词：RDB、AOF、SAVE、BGSAVE、appendfsync

img

# Redis 复制

关键词：SLAVEOF、SYNC、PSYNC、REPLCONF ACK

img

# Redis 哨兵

Redis 哨兵（Sentinel）是 Redis 的高可用性（Hight Availability）解决方案。

Redis 哨兵是 Raft 算法 的具体实现。

关键词：Sentinel、PING、INFO、Raft

img

# Redis 集群

关键词：CLUSTER MEET、Hash slot、MOVED、ASK、SLAVEOF no one、redis-trib

img

# Redis 实战

关键词：缓存、分布式锁、布隆过滤器

# Redis 运维 🔨

关键词：安装、命令、集群、客户端

# 📚 资料

# 🚪 传送

◾ 💧 钝悟的 IT 知识图谱 (opens new window) ◾ 🎯 钝悟的博客 (opens new window) ◾

+
+ +
📝 帮助改善此页面！ (opens new window)
#数据库#KV数据库#Redis
上次更新: 2023/06/29, 22:27:04
最近更新
01
+ HBase Java API 管理功能 +
04-13
02
+ HBase Java API 其他高级特性 +
03-31
03
+ HBase 数据模型 +
03-16
更多文章>
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + + diff --git a/tags/index.html b/tags/index.html new file mode 100644 index 00000000..a4289a01 --- /dev/null +++ b/tags/index.html @@ -0,0 +1,67 @@ + + + + + + 标签 | DB-TUTORIAL + + + + + + + + + + +
DB-TUTORIAL
全部标签
大数据 HBase API 数据库 列式数据库 关系型数据库 SQL 搜索引擎数据库 Elasticsearch 索引 综合 中间件 Elastic 数据结构 集群 分片 高亮 分词 性能 排序 聚合 查询 分库分表 文档数据库 MongoDB 事务 复制 Mysql FAQ 建模 运维 锁 KV数据库 Redis 面试 数据类型 持久化 哨兵 Filebeat Kibana Logstash 配置 Nosql 版本管理 PostgreSQL H2 SQLite Cassandra

+ HBase Java API 管理功能 +

dunwu 2023-04-13 数据库列式数据库HBase 大数据HBaseAPI

+ HBase Java API 其他高级特性 +

dunwu 2023-03-31 数据库列式数据库HBase 大数据HBaseAPI

+ HBase 数据模型 +

dunwu 2023-03-16 数据库列式数据库HBase 数据库列式数据库大数据HBase

+ HBase Java API 高级特性之协处理器 +

dunwu 2023-03-16 数据库列式数据库HBase 大数据HBaseAPI

+ HBase Java API 高级特性之过滤器 +

dunwu 2023-03-16 数据库列式数据库HBase 大数据HBaseAPI

+ HBase Schema 设计 +

dunwu 2023-03-15 数据库列式数据库HBase 大数据HBase

+ HBase Java API 基础特性 +

dunwu 2023-03-15 数据库列式数据库HBase 大数据HBase

+ SQL Cheat Sheet +

dunwu 2022-07-16 数据库关系型数据库综合 数据库关系型数据库SQL

+ Elasticsearch 映射 +

dunwu 2022-05-16 数据库搜索引擎数据库Elasticsearch 数据库搜索引擎数据库Elasticsearch索引

+ SQL 语法高级特性 +

dunwu 2022-04-27 数据库关系型数据库综合 数据库关系型数据库SQL
全部标签
大数据 HBase API 数据库 列式数据库 关系型数据库 SQL 搜索引擎数据库 Elasticsearch 索引 综合 中间件 Elastic 数据结构 集群 分片 高亮 分词 性能 排序 聚合 查询 分库分表 文档数据库 MongoDB 事务 复制 Mysql FAQ 建模 运维 锁 KV数据库 Redis 面试 数据类型 持久化 哨兵 Filebeat Kibana Logstash 配置 Nosql 版本管理 PostgreSQL H2 SQLite Cassandra
+ Theme by + Vdoing + | Copyright © 2019-2023 + 钝悟（dunwu） | CC-BY-SA-4.0
×
+
+ +
+ + +