㈠ mysql怎樣分庫
1
基本思想之什麼是分庫分表？
從字面上簡單理解，就是把原本存儲於一個庫的數據分塊存儲到多個庫上，把原本存儲於一個表的數據分塊存儲到多個表上。
2
基本思想之為什麼要分庫分表？
資料庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增刪改查的開銷也會越來越大；另外，由於無法進行分布式式部署，而一台伺服器的資源（cpu、磁碟、內存、io等）是有限的，最終資料庫所能承載的數據量、數據處理能力都將遭遇瓶頸。
3
分庫分表的實施策略。
分庫分表有垂直切分和水平切分兩種。
3.1
何謂垂直切分，即將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義資料庫workdb、商品資料庫paydb、用戶資料庫userdb、日誌資料庫logdb等，分別用於存儲項目數據定義表、商品定義表、用戶數據表、日誌數據表等。
3.2
何謂水平切分，當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如userid散列，進行劃分，然後存儲到多個結構相同的表，和不同的庫上。例如，我們的userdb中的用戶數據表中，每一個表的數據量都很大，就可以把userdb切分為結構相同的多個userdb：part0db、part1db等，再將userdb上的用戶數據表usertable，切分為很多usertable：usertable0、usertable1等，然後將這些表按照一定的規則存儲到多個userdb上。
3.3
應該使用哪一種方式來實施資料庫分庫分表，這要看資料庫中數據量的瓶頸所在，並綜合項目的業務類型進行考慮。
如果資料庫是因為表太多而造成海量數據，並且項目的各項業務邏輯劃分清晰、低耦合，那麼規則簡單明了、容易實施的垂直切分必是首選。
而如果資料庫中的表並不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬於一體的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，後期也將對項目人員及應用程序產生額外的數據管理負擔。
在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對資料庫進行垂直切分，然後，再針對一部分表，通常是用戶數據表，進行水平切分。
4
分庫分表存在的問題。
4.1
事務問題。
在執行分庫分表之後，由於數據存儲到了不同的庫上，資料庫事務管理出現了困難。如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
4.2
跨庫跨表的join問題。
在執行了分庫分表之後，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位於不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。
4.3
額外的數據管理負擔和數據運算壓力。
額外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重復執行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對於一個記錄用戶成績的用戶數據表usertable，業務要求查出成績最好的100位，在進行分表之前，只需一個order
by語句就可以搞定，但是在進行分表之後，將需要n個order
by語句，分別查出每一個分表的前100名用戶數據，然後再對這些數據進行合並計算，才能得出結果。
上述整理於互聯網
㈡ 在一台機器上，怎麼安裝多個mysql資料庫，怎樣開啟多個mysql服務，。在線等，
這種架構一般用在以下三類場景
1. 備份多台 Server 的數據到一台如果按照數據切分方向來講，那就是垂直切分。比如圖 2，業務 A、B、C、D 是之前拆分好的業務，現在需要把這些拆分好的業務匯總起來備份，那這種需求也很適用於多源復制架構。實現方法我大概描述下：業務 A、B、C、D 分別位於 4 台 Server，每台 Server 分別有一個資料庫來隔離前端的業務數據，那這樣，在從庫就能把四台業務的數據全部匯總起來，而不需要做額外的操作。那沒有多源復制之前，要實現這類需求，只能在匯總機器上搭建多個 MySQL 實例，那這樣勢必會涉及到跨庫關聯的問題，不但性能急劇下降，管理多個實例也沒有單台來的容易。
㈢ 資料庫Oracle跨越資料庫的不同實例之間創建link後，我就可以實現查詢，這個我會，但是現在，本
實例不同，TNSName就不同，仍然按你會的跨庫創建DBLink來訪問吧，只是Host相同而已、不奇怪。
㈣ 如何在單個Boot應用中配置多資料庫
為什麼需要多資料庫？
默認情況下，Spring Boot使用的是單資料庫配置（通過spring.datasource.*配置具體資料庫連接信息）。
對於絕大多數Spring Boot應用，這是符合其使用場景的，因為Spring Boot提倡的是微服務理念，每個應用對應一個單獨的業務領域。但在某些特殊情況下，一個應用對應多個資料庫又是無法避免的，例如實施資料庫分庫後原本單個資料庫變為多個資料庫。本文就結合實際代碼介紹如何在單個Boot應用中配置多資料庫，以及與之相關的Druid，jOOQ，Flyway等數據服務框架的配置改造。
配置示例
DB1，DB2: 兩個示例資料庫
ServiceA, ServiceB: 分別使用DB1和DB2的服務類
連接池Druid
Druid是阿里巴巴開源的資料庫連接池，提供了強大的監控支持，號稱Java語言中最好的連接池。
創建兩個配置類分別注冊對應DB1和DB2的DataSource Bean和TransactionManager Bean。以DB1為例：
Tip: 可以把其中一個配置類中注冊的DataSource Bean和DataSourceTransactionManager Bean加上@Primary註解，作為默認裝配實例。
// DB1
@Configuration
public class Db1Config {
@Bean(initMethod = "init", destroyMethod = "close")
@ConfigurationProperties(prefix = "db.db1")
public DataSource dataSource1() {
return new DruidDataSource();
}
@Bean
public DataSourceTransactionManager transactionManager1() {
DataSourceTransactionManager transactionManager = new DataSourceTransactionManager();
transactionManager.setDataSource(dataSource1());
return transactionManager;
}
}
application.conf中的配置：
# DB1
db.db1.url=jdbc:mysql://127.0.0.1:3306/db1?useUnicode=true&characterEncoding=UTF-8&rewriteBatchedStatements=true
db.db1.username=root
db.db1.password=
ORM框架jOOQ
jOOQ是一個開源ORM框架，最大特點是提供類型安全的流式API，支持代碼生成。
參照Boot自帶的JooqAutoConfiguration，不難寫出如下配置類：
@Configuration
public class JooqConfig {
// DB1
@Bean
public DataSourceConnectionProvider dataSourceConnectionProvider1(
@Qualifier("dataSource1") DataSource dataSource1) {
return new DataSourceConnectionProvider(
new (dataSource1));
}
@Bean
public SpringTransactionProvider transactionProvider1(
@Qualifier("transactionManager1") DataSourceTransactionManager txManager1) {
return new SpringTransactionProvider(txManager1);
}
// DB2
// ...
@Configuration
public static class DslContextConfig {
@Autowired(required = false)
private RecordMapperProvider recordMapperProvider;
@Autowired(required = false)
private Settings settings;
@Autowired(required = false)
private RecordListenerProvider[] recordListenerProviders;
@Autowired
private ExecuteListenerProvider[] executeListenerProviders;
@Autowired(required = false)
private VisitListenerProvider[] visitListenerProviders;
// DSLContext for DB1
@Bean
public DefaultDSLContext dslContext1(@Qualifier("dataSourceConnectionProvider1") DataSourceConnectionProvider connectionProvider1,
@Qualifier("transactionProvider1") SpringTransactionProvider transactionProvider1) {
return new DefaultDSLContext(configuration(connectionProvider1, transactionProvider1));
}
// DSLContext for DB2
// ...
private DefaultConfiguration configuration(ConnectionProvider connectionProvider, TransactionProvider transactionProvider) {
DefaultConfiguration configuration = new DefaultConfiguration();
configuration.setSQLDialect(SQLDialect.MYSQL);
configuration.set(connectionProvider);
configuration.set(transactionProvider);
if (this.recordMapperProvider != null) {
configuration.set(this.recordMapperProvider);
}
if (this.settings != null) {
configuration.set(this.settings);
}
configuration.set(this.recordListenerProviders);
configuration.set(this.executeListenerProviders);
configuration.set(this.visitListenerProviders);
return configuration;
}
}
}
服務類
配置好DataSource，TransacationManager和DSLContext之後，服務類的配置就比較簡單了，直接引用即可。注意由於存在多套Beans，需要通過@Qualifier註解指定裝配實例。
@Transactional("TransactionManager1")//每個事務指定 tx
public class ServiceA {
@Autowired
@Qualifier("dslContext1")
protected DSLContext dsl;
}
資料庫遷移框架Flyway
Flyway是一個輕量級的開源資料庫遷移框架，使用非常廣泛。
參照Boot自帶的FlywayAutoConfiguration，同樣可以寫出如下配置類：
@Configuration
public class FlywayConfig {
@Bean(initMethod = "migrate")
@ConfigurationProperties(prefix = "fw.db1")
public Flyway flyway(@Qualifier("dataSource1") DataSource dataSource1) {
Flyway clinic = new Flyway();
clinic.setDataSource(dataSource1);
return clinic;
}
// DB2
// ...
/**
* @see FlywayAutoConfiguration
*/
@Bean
@
public () {
return new ();
}
/**
* Convert a String or Number to a {@link MigrationVersion}.
* @see FlywayAutoConfiguration
*/
private static class
implements GenericConverter {
private static final Set<ConvertiblePair> CONVERTIBLE_TYPES;
static {
Set<ConvertiblePair> types = new HashSet<ConvertiblePair>(2);
types.add(new ConvertiblePair(String.class, MigrationVersion.class));
types.add(new ConvertiblePair(Number.class, MigrationVersion.class));
CONVERTIBLE_TYPES = Collections.unmodifiableSet(types);
}
@Override
public Set<ConvertiblePair> getConvertibleTypes() {
return CONVERTIBLE_TYPES;
}
@Override
public Object convert(Object source, TypeDescriptor sourceType,
TypeDescriptor targetType) {
String value = ObjectUtils.nullSafeToString(source);
return MigrationVersion.fromVersion(value);
}
}
}
application.conf中的配置：
# DB1
fw.db1.enabled=true
㈤ 資料庫為什麼要分庫分表及實現策略
1 基本思想之什麼是分庫分表？
從字面上簡單理解，就是把原本存儲於一個庫的數據分塊存儲到多個庫上，把原本存儲於一個表的數據分塊存儲到多個表上。
2 基本思想之為什麼要分庫分表？
資料庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增刪改查的開銷也會越來越大；另外，由於無法進行分布式式部署，而一台伺服器的資源（CPU、磁碟、內存、IO等）是有限的，最終資料庫所能承載的數據量、數據處理能力都將遭遇瓶頸。
3 分庫分表的實施策略。
分庫分表有垂直切分和水平切分兩種。
3.1 何謂垂直切分，即將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義資料庫workDB、商品資料庫payDB、用戶資料庫userDB、日誌資料庫logDB等，分別用於存儲項目數據定義表、商品定義表、用戶數據表、日誌數據表等。
3.2 何謂水平切分，當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如userID散列，進行劃分，然後存儲到多個結構相同的表，和不同的庫上。例如，我們的userDB中的用戶數據表中，每一個表的數據量都很大，就可以把userDB切分為結構相同的多個userDB：part0DB、part1DB等，再將userDB上的用戶數據表userTable，切分為很多userTable：userTable0、userTable1等，然後將這些表按照一定的規則存儲到多個userDB上。
3.3 應該使用哪一種方式來實施資料庫分庫分表，這要看資料庫中數據量的瓶頸所在，並綜合項目的業務類型進行考慮。
如果資料庫是因為表太多而造成海量數據，並且項目的各項業務邏輯劃分清晰、低耦合，那麼規則簡單明了、容易實施的垂直切分必是首選。
而如果資料庫中的表並不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬於一體的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，後期也將對項目人員及應用程序產生額外的數據管理負擔。
在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對資料庫進行垂直切分，然後，再針對一部分表，通常是用戶數據表，進行水平切分。
4 分庫分表存在的問題。
4.1 事務問題。
在執行分庫分表之後，由於數據存儲到了不同的庫上，資料庫事務管理出現了困難。如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
4.2 跨庫跨表的join問題。
在執行了分庫分表之後，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位於不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。
4.3 額外的數據管理負擔和數據運算壓力。
額外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重復執行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對於一個記錄用戶成績的用戶數據表userTable，業務要求查出成績最好的100位，在進行分表之前，只需一個order by語句就可以搞定，但是在進行分表之後，將需要n個order by語句，分別查出每一個分表的前100名用戶數據，然後再對這些數據進行合並計算，才能得出結果。
上述整理於互聯網
㈥ 資料庫為什麼要分庫分表
1 基本思想之什麼是分庫分表？
從字面上簡單理解，就是把原本存儲於一個庫的數據分塊存儲到多個庫上，把原本存儲於一個表的數據分塊存儲到多個表上。
2 基本思想之為什麼要分庫分表？
數
據庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增
刪改查的開銷也會越來越大；另外，由於無法進行分布式式部署，而一台伺服器的資源（CPU、磁碟、內存、IO等）是有限的，最終資料庫所能承載的數據量、
數據處理能力都將遭遇瓶頸。
3 分庫分表的實施策略。
分庫分表有垂直切分和水平切分兩種。
3.1
何謂垂直切分，即將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義資料庫workDB、商品資料庫payDB、用戶數據
庫userDB、日誌資料庫logDB等，分別用於存儲項目數據定義表、商品定義表、用戶數據表、日誌數據表等。
3.2
何謂水平切分，當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如userID散列，進行劃分，然後存儲到多個結構相同的表，和不同的庫
上。例如，我們的userDB中的用戶數據表中，每一個表的數據量都很大，就可以把userDB切分為結構相同的多個userDB：part0DB、
part1DB等，再將userDB上的用戶數據表userTable，切分為很多userTable：userTable0、userTable1等，
然後將這些表按照一定的規則存儲到多個userDB上。
3.3 應該使用哪一種方式來實施資料庫分庫分表，這要看資料庫中數據量的瓶頸所在，並綜合項目的業務類型進行考慮。
如果資料庫是因為表太多而造成海量數據，並且項目的各項業務邏輯劃分清晰、低耦合，那麼規則簡單明了、容易實施的垂直切分必是首選。
而
如果資料庫中的表並不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬於一體
的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，後期也將對項目人員及應用程序產生額外的數據管理負擔。
在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對資料庫進行垂直切分，然後，再針對一部分表，通常是用戶數據表，進行水平切分。
4 分庫分表存在的問題。
4.1 事務問題。
在執行分庫分表之後，由於數據存儲到了不同的庫上，資料庫事務管理出現了困難。如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
4.2 跨庫跨表的join問題。
在執行了分庫分表之後，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位於不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。
4.3 額外的數據管理負擔和數據運算壓力。
額
外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重復執行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對於
一個記錄用戶成績的用戶數據表userTable，業務要求查出成績最好的100位，在進行分表之前，只需一個order
by語句就可以搞定，但是在進行分表之後，將需要n個order
by語句，分別查出每一個分表的前100名用戶數據，然後再對這些數據進行合並計算，才能得出結果。
㈦ springerlink資料庫資源包括哪些
Springer Link全文資料庫
德國施普林格（Springer-Verlag）是世界上著名的科技出版社，該社通過Springer Link系統發行電子圖書並提供學術期刊檢索服務。目前共出版有530餘種期刊，其中498種已有電子版，其檢索系統名稱為Link。
SpringerLink通過純數字模式的專家評審編輯程序，從以卷期為單位的傳統印刷出版標准過渡到以單篇文章為單位的網路出版標准，現在已有超過200種期刊優先以電子方式出版（OnlineFirst），大大提高了文獻網上出版的速度和效率，並保持了文獻的高質量要求。Springer的發展目標是把OnlineFirst出版方式應用到所有SpringerLink提供全文服務的期刊上。
SpringerLink電子期刊（全文）的學科覆蓋有：生命科學Life Science (134種)、化學Chemical Sciences（52種）、地球科學Geoscience (61種)、計算機科學Computer Science（49種）、數學Mathematics（80種）、醫學Medicine (221種)、物理與天文學Physics and Astronomy (58種)、工程學Engineering (61種)、環境科學Environmental (42 種)、經濟學Economics (32種)和法律Law (12種)等（由於一些期刊內容在學科上的交叉，故存在同一種期刊被劃分在多個學科的情況），其中大部分期刊是被SCI、SSCI和EI收錄的核心期刊，是科研人員的重要信息源。
參考資料： http://ke..com/view/1060718.htm
㈧ sqlserver資料庫的分庫該怎麼實現
sql server 2008資料庫分離操作跟sql server 2005是一樣的，以下具體介紹如何分離sql server 資料庫：
1、打開 sql server 控制台（SQL Server Management Studio），然後登錄。
2、登錄時如果知道sa密碼可以使用「SQL Server身份驗證」模式登錄，如果不知道sa密碼可以使用「windows身份驗證」模式登錄就不需要密碼登錄。而sql server 2008的用戶一般是在安裝的時候自定義的用戶，但也可以使用「windows身份驗證」模式登錄。
3、登錄到控制到中之後，找到【資料庫】點擊展開，然後找到你所需要分離的資料庫名稱。選中資料庫【右鍵】-【任務】-【分離】即可。
附件說明：分離資料庫一般是需要將資料庫拷貝到其他機器或者是移動磁碟時和不需要使用該資料庫的情況下才做資料庫分離。資料庫一旦分離之後所對應的軟體將無法正常使用和打開資料庫。如果需要重新將資料庫還原到資料庫控制台中，選中【資料庫】-【右鍵】-【附加】，找到你所要附件的數據所在的磁碟路徑，選擇以「.MDF」為後綴的文件即可。
㈨ springerlink資料庫的高級檢索怎麼用
1、點擊右側的「高級檢索」，進入高級檢索首頁。
㈩ 資料庫為什麼分庫分表
資料庫涉及各種領域。即使同一領域也有不同需求，且有各種資料庫軟體，分庫是很正常的。一個資料庫內需要各種關系表，來避免冗餘信息，使得資料庫儲存、檢索效率提高。
資料庫(Database)是按照數據結構來組織、存儲和管理數據的倉庫，它產生於距今六十多年前，隨著信息技術和市場的發展，特別是二十世紀九十年代以後，數據管理不再僅僅是存儲和管理數據，而轉變成用戶所需要的各種數據管理的方式。資料庫有很多種類型，從最簡單的存儲有各種數據的表格到能夠進行海量數據存儲的大型資料庫系統都在各個方面得到了廣泛的應用。
在信息化社會，充分有效地管理和利用各類信息資源，是進行科學研究和決策管理的前提條件。資料庫技術是管理信息系統、辦公自動化系統、決策支持系統等各類信息系統的核心部分，是進行科學研究和決策管理的重要技術手段。