运行我的Grails 2.2.1应用程序需要近3个小时才能启动，无论是使用run-app还是部署为战争。
通常的日志记录，然后很长一段时间都没有，然后是通常的日志记录。所以我打开了hibernate show_sql和use_sql_comments，发现hibernate对select语句很疯狂 - 几乎就是一百万个。
示例：
Hibernate：/ * load com.sommelier.domain.core.Venue * / select venue0_.id as id12_0_，venue0_.version as version12_0_，venue0_.address1 as address3_12_0_，venue0_.address2 as address4_12_0_，venue0_.address3 as address5_12_0_， .....（为隐私而截断）
Hibernate：/ * criteria query * /选择this_.id为id90_0_，this_.version为version90_0_，this_.name为name90_0_，this_.subregion_id为subregion4_90_0_，来自subarea this_ order by this_.id asc
Hibernate：/ *加载一对多com.sommelier.domain.changes.ChangeInfo.changeItems * /选择changeitem0_.change_info_id为change3_29_1_，changeitem0_.id为id1_，changeitem0_.id为id143_0_，changeitem0_.version为version143_0_ ，changeitem0_.change_info_id为change3_143_0_，changeitem0_.new_value为new4_143_0_，changeitem0_.old_value为old5_143_0_，changeitem0_.value_name为value6_143_0_ from change_item changeitem0_ where changeitem0_.change_info_id =？
休眠：/ *集合负载* com.sommelier.domain.core.VenueThing.inventorySortOrders /选择inventorys0_.inventory_sort_orders作为inventory1_44_0_，inventorys0_.inventory_sort_orders_elt如inventory3_0_，inventorys0_.inventory_sort_orders_idx如inventory2_0_从venue_wine_inventory_sort_orders inventorys0_其中inventorys0_.inventory_sort_orders = <？ / p>
应用程序始终开始缓慢，大约15分钟，这至少是可以忍受的，但我最近在一个域中添加了一个大型集合属性，并且它膨胀到三个小时。所以我认为这是一个与最新变化无关的问题 - 它只是让症状变得更糟。
那为什么要这样做呢？它在创建索引吗？还是缓存？还是代理？是否实际执行了select语句，或者只是创建它们并保存它们以便将来运行？
我尝试删除每个可疑插件都无济于事。在我的任何域类中都没有任何异常。所有这些都发生在调用Bootstrap.groovy之前。是否有任何代码在Bootstrap之前运行？
我没有hibernate.xml文件 - 应该有吗？
答案 0 :(得分：0)
感谢Justas建议在代码中添加日志记录。我更新了Config.groovy中的log4j设置，为“org.hibernate”，“org.springframework”和“org.codehaus.groovy.grails.plugins”记录了“all”（不知道哪个人做了伎俩），以及很明显，hibernate代表“Compass Gps Index”工作。
稍后有点谷歌搜索，罪魁祸首是可搜索的插件。
在我之前尝试找到我已删除的问题
compile ":searchable:0.6.4"
，因为它是一个插件问题，但显然该插件仍以某种方式运行。
所以我刚刚将以下内容添加到Config.groovy：
searchable {
bulkIndexOnStartup = false
}
现在我在75秒内启动。从3小时到75秒!!
不确定删除索引会产生什么后果，但现在我知道我可以解决它的问题了。